Re: Permitting non-indirect links

At 3:28 AM 1/14/97, Martin Bryan wrote:
>At 11:56 13/1/97 -0500, David G. Durand wrote:
>>Can't this be done with general entity references?
>>
>><a href="http://&base-server;/&rootpath;/&this-subject-path;/&this-doc">
>
>There are two problems with this appoach. One is the need to define entities
>for each part of each URL in the BOS or document, and the second is that
>each link has to look different so my second link has to read:
><a href="http://&base-server2;/&rootpath2;/&that-subject-path;/&that-doc">

They only have to look this different if it uses a different server,
different root path, different subject path, and different document path.
You asked for the ability to use indirection to manage URLs, and I don't
see that any two _different_ URLs can avoid having some difference in their
markup, no matter how you indirect. I used entities everywhere, but it
would be easy to put some fixed document names or path components anywhere
they are wanted.

Declaring entities is no harder than the extra elements that the HyTime
approach would require.

>A more user friendly approach is:
>
><a URL-method="http" URL-DNS="www.echo.lu" URL-path="oii/en"
>URL-file="alpha.html" URL-fragment="X">

This seems syntactically equivalent to a hard-coded link. Where does the
indirection come in in this example?

Field names are nice, but since entities already exist, and they seem to do
what you want pretty transparently, I think a new syntax is just not
needed.

>This is the same as the capture on HoTMetaL, but instead of resolving the
>whole URL into a single string at capture stage it leaves the resolution to
>the point at which calling of the file is needed.

I don't understand this sentence. The above example has a seriws of
hard-wired values, and seems utterly equivalent to the following:
<a URL="http://www.echo.lu/"oii/en/alpha.html#X>

I see the breakup of the URL into attribute values, but I don't see that
this does anything but save a programmer from writing a 50-line URL parser.

>With indirection of the strings to XML location address IDREFS (beginning
>xla for clarity) this would become:
>
><a URL-method=http XML-DNS=xla12345 XML-path=xla34567 XML-file=xla98765
>XML-fragment=xla76345>

Now we see some indirection, but how does it differ semantically from:
<a URL="http://&xla12345;/&xla34567;/xla34567;alpha.html#X">

(I have flattened some things that were indirected to constants as xla
isn't that clear to me).

I see only a syntactic difference, not a semantic one.

>>HyTime location ladders can specify this, and I think that the use of
>>relative URLs, along with the location facilities we have been talking
>>about, would actually let you do the equivalent with links.
>
>The problem is that HyTime location ladders don't seem to allow you to point
>to subsections of location sources. For example, can I do a location address
>just to a DNS, and then another just to a directory path at the DNS. I don't
>think I can using pure HyTime, but I would sure like to for XML link >
>management.

You could do something like this, I think (Eliot: apologies for any
syntactic gaffes, but I am prety sure of the semantics)

<a dest="url-chain">
<location id="url-chain" locsrc="chain1" url="#x">
<location id="chain1" locsrc="chain2" url="alpha.html">
<location id="chain2" locsrc="chain3" url="/oii/en/"

etc...

We would need to define that relative URL semantics apply when a URL is the
locsrc for a URL. This makes sense.

However, I don't like the HyTime solution that much, as locsrc has all the
decoupling problems of ilink, but offers less obvious value.

I am not saying that it's worthless, but I think we can live without locsrc
and still have a _lot_ of power.

As far as I know, the attribute value syntax that martin is proposing could
not be a valid HyTime location latter (though it could of course be a
query, since any markup at all can be defined as a query).

So Martin's proposed markup is only HyTime compatible in the weakest way.

>Similarly the SOIBase concept of formal system identifiers does not allow
>for segmentation of the base, which is what I am asking for.

Entities can be used in the same way there too.

Now I know that entities are (over) used in SGML to make up for language
deficiencies, but I think that URL composition is actually a pretty natural
use of entities: certainly it would not take long to explain to authors.
And although it is somewhat verbose, any indirection as powerful as Martin
seems to want is going to be verbose, so I don't feel that we're condemning
naive users to endless obscurity if we decide that entities are good
enough.

   -- David

I am not a number. I am an undefined character.
_________________________________________
David Durand              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
Boston University Computer Science        \  Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
--------------------------------------------\  http://dynamicDiagrams.com/
MAPA: mapping for the WWW                    \__________________________

Received on Tuesday, 14 January 1997 12:38:40 UTC