Re: Radical cure for BOS confusion

At 12:47 PM 1/6/97 -0800, Jon Bosak wrote:
>We implement alinks just the way that Eliot is proposing, which (if I
>understand him correctly) means to the naive user that an element
>tagged <alink...> will by default behave as if we had actually
>reserved the name "alink" in XML, though of course we can override
>this in a supplied DTD (if this isn't what Eliot is proposing, then I
>think that he should), 

That's exactly what I meant.

and that we can make other elements into alinks
>by declaring them to be so in a DTD or by using a reserved attribute
>that says that they are alinks even in the absence of a DTD (again, if
>this is not what's being proposed, then I would like to propose it).

Again, exactly what I meant.

>So to the naive user, an XML alink is an improved version of an HTML
><A HREF>.  So far, so cool.

That's the idea.

>For hlinks (nee ilinks) -- here comes the radical part -- we could
>take Dave Durand's "companion document" idea to a logical extreme.  We
>could define a special document type (i.e., provide a standard DTD)
>for something called, say, "linkset" that is nothing but a collection
>of hlinks (plus whatever other linking/addressing stuff we find useful
>to put in there).  In doing so, we would entirely eliminate the idea
>that ordinary documents could contain hlinks; they could only contain
>alinks.  Then linksets (collections of hlinks) would exist for just
>one purpose: the creation and management of links that stand outside
>of individual documents.  This is, I believe, something like what
>Steve Newcomb has been calling a "subhub", but radically simplified by
>specifying a fixed tagset, eliminating all ordinary document content
>from linksets, and forbidding the use of independent links in ordinary


>Intuition tells me that this must be too simple, but I would very much
>like to know why.  What's wrong with this picture?

I think this is a perfectly reasonable solution: it's essentially what
Panorama does with it's "web" files, which are nothing more than a set of
ilinks and their attendant location addresses, plus a little
Panorama-specific metadata.

I don't see anything in this proposal that would limit the ability to do more.


W. Eliot Kimber (eliot@isogen.com) 
Senior SGML Consulting Engineer, Highland Consulting
2200 North Lamar Street, Suite 230, Dallas, Texas 75202
+1-214-953-0004 +1-214-953-3152 fax
http://www.isogen.com (work) http://www.drmacro.com (home)
"Rats in the morning, rats in the afternoon...if they don't go away, I'll be
re-educated soon..."                 --Austin Lounge Lizards, "1984 Blues"