Re: Permitting non-indirect links

At 09:19 AM 01/09/97 +0000, Martin Bryan wrote:
>At 15:51 8/1/97 -0500, Steven J. DeRose wrote:
>
>> Since SGML doesn't provide inter-book linking syntax,
>
>But WG8 have already proposed the form IDREF "#ENTITY ent-name id" for this

That hardly diminishes the force of my point. Nearly every DTD "proposed"
this years ago. That's why there's TONS of legacy data out there. Adding a
construct that's kind-of-similar to terabytes of existing data doesn't help
the owners of that data quite as much as grandfathering them in as-is
(especially since the cost to do so is basically nil -- care to estimate the
cost/likelihood of inserting "#ENTITY " into all the right places in all
those documents?)

>
>>HyTime (until the TC) provided no support for cases similar to this. So, all
>>those documents would have to be re-authored even though what they're doing
>>is reasonable.
>
>How many HyTime books would need to be reauthored for Web delivery?
>(Do I need a second pair of hands to count them?)

By definition, ZERO HyTime books would, because if a document uses the
construct now it is not a HyTime book (at least, the links in question are
not HyTime, even if someone adds other constructs that are). But an
*enormous* number of non-HyTime books would immediately become
HyTime-conforming if HyTime (and now us) took account of the most common
linking construct out there rather than just declaring it not to be of interest.

You see, that's the *point*. HyTime didn't support it (despite official
comments), and so all the existing legacy data that *could* have been easily
supported is gratuitously non-conforming. Now that it's being fixed in
HyTime let's not repeat the error in XML by prohibiting it there!


>There's no question that we need to allow a construct for embedded links to
>URLs. The question is whether this is really a "comparably simple construct"
>which might require the authors to re-author their links or an "link
>identifying architectural form" that can be used to tell XML browsers that
>this existing element is to be processed as if it were an XML link. I
>contend the latter is what is needed.

Fine, so let's *do* it.

>
>>A link with a URL on an attribute is structurally the same, it just has
>>slightly different syntax: it combines the two attributes into one, and it
>>puts a system identifier (essentially) right there, instead of indirecting
>>through the DTD.
>
>The problem is that because it is not indirected it cannot be managed. XML
>must have manageable links if we are to get people to move from the simple
>world of HTML to the more complex world of XML.

It is not always true that links which are not indirected cannot be managed.
For *some purposes* it is true; for other just the opposite is true. But the
point is that HyTime (and XML) are meant to be inclusive, and it is wrong to
impose a particular implementation model on the entire community.

>
>> Lots of SGML "cheats" with public or system ids on
>>attributes, rather than indirecting through entity declarations. We can say
>>that's awful if we like, but its frequency shows it is attractive, perhaps
>>because:
>>
>>a) it keeps the whole reference in once place, which greatly simplifies
>>readability and maintainability.
>
>The last thing we want is to keep the "whole reference in one place" - thats
>just the problem with managing URLs. They are kept all over the place, not
>at a central, controllable point.

Eh? You just say that the *last* thing we want is to keep the link whole,
but then you say the *problem* with URLs is that they're *not* whole -- what
am I missing here? Do you actually believe it's easier to manage a link that
exists in 20 different elements scattered around a document joined only by
IDREFs with each rung separately editable and deletable, than to manage one
element? I would need to see a rather better argument to believe that.

>
>>b) it keeps authors from having to learn a second language, namely that of
>>markup declarations, so it's easier to teach, and easier to create UIs for.
>
>Who wants to teach authors - I want authoring tools that do it all for me!

I rest my case on this point.

>On my site 10% of the entities are referenced more than 20 times, and 30-40%
>are referenced more than once. The phrase "off chance" hardly applies! The
>overhead for referencing the ones only pointed to once is more than offset
>by those that are referenced many many times.

If I recall correctly, I was not claiming that indirection was evil and
should be destroyed. Merely the far less draconian claim that *direct* links
can also be useful, and in *some* cases have substantial advantages. Are you
prepared to claim that your data is the *only* kind anyone should ever have?

Received on Friday, 10 January 1997 15:06:38 UTC