W3C home > Mailing lists > Public > w3c-sgml-wg@w3.org > January 1997

Re: Permitting non-indirect links

From: Martin Bryan <mtbryan@sgml.u-net.com>
Date: Sat, 11 Jan 1997 11:58:52 +0000
Message-Id: <>
To: "Steven J. DeRose" <sjd@ebt.com>, w3c-sgml-wg@www10.w3.org
At 15:04 10/1/97 -0500, Steven J. DeRose wrote:

>>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.

Depends what you mean by "managed". I "manage" a load of links that are
embedded in documents by running manual checks on them, but I cannot
efficiently automate the system as I don't get enough information from the
Web about them. OK I run the standard checking software, but that only tells
me when an error occurs, not when the data in the file has been changed,
moved to another site, replaced by a pointer saying that the file can be
found elsewhere, etc. This is what I want my "data management module" to be
able to handle in the longer term. I can do this most efficiently with
indirected links, and least efficiently with the links embedded at random
points in my data. 

>>> 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
>>>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?

Don't confuse my keeping the "whole reference in one place" with your "keep
the link whole" - I stongly suspect we are talking about different things.
The fact is that a URL location is not a whole. Let me give you a simple
example. My files were recently moved, for management reasons totally out of
my control, to a new subdirectory at the same server. I did not want people
pointing to my files to have to change the site identifier but I did want
them to change the path they were using. I did not want them to change the
file name or any any of the fragment identifiers. How can I easily tell them
what they have to do to update their URLs?  You cannot look at site
management without looking at URLs as segments of useful information.

> 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

Link management becomes infinitely easier if you construct separate
identifier components for the site, directory path, filename and fragment
path and then "build URLs" at the point they are needed by pointing to the
one location that contains this inforamtion using invariant names assigned
to these components. If you need convincing of this look at the URL entry
form in HoTMetal. Why is it that this does not just have a single entry
point for a "complete" URL.

> I would need to see a rather better argument to believe that.

Convinced of the benefits yet? Now the big question is, can we do this using
HyTime? I wish I knew the answer to that one!

>>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?

No more than I am claiming that embedded links are not useful. I'm simply
arguing that there are advantages in allowing both approaches
simultaneously, and am arguing strongly that the more complicated case
should not be swamped by the KISS brigade.

Martin Bryan
Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK 
Phone/Fax: +44 1452 714029   WWW home page: http://www.u-net.com/~sgml/
Received on Saturday, 11 January 1997 07:01:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:25:06 UTC