Re: If no new syntax, and no API, then what are we doing here . . .

I said, in summary:
>  The xml-link document should define a new Property Set
>  module, with an HLINK class to represent links, with HLINKTYPE and
>  ENDPOINTS properties.  There's an ENDPOINT class as well,
>  with something like TYPE, NODELOC and DATALOC properties.
>  
>  On this account the result of processing an XML document with link
>  definition elements in it is TWO groves:  the document grove and a
>  link grove.  NODELOC properties will be (lazy) pointers into the
>  groves of (..ML) documents, while DATALOC is for non-SGML endpoints.

As promised, a bit more.

1) Note that I don't mean by the link grove proposal to say that all
XML parsers have to buy in to the grove model, just that groves are a
useful language for answering the question Jon implicitly asked a
while back, namely, what do Applications have to work with when
processing links.  The link grove proposal answers that question in
the abstract---the concrete representation of that information is up
to implementors.

2) I'm sure a lot of this is crypto-HyTime, and Eliot would have said
it first if he weren't too busy.

3) Using TC language again, the 'link description' in my terminology
is pretty much isomorphic to the node in the document grove derived
from the link description element, as that node has (directly or
indirectly) all the relevant information in its properties.  On this
account, we'd add a new (urefnode) HLINK property to the ELEMENT class, which
would point to the appropriate HLINK node in the link grove from all
such element nodes.

4) Note that since most locators take a lot of work to chase, the
laziness of HLINK.ENDPOINTS is important, with the values of
ENDPOINT.NODELOC properties on HLINK nodes in the link grove just
being a node and property version of the original locators, with in a
few cases, e.g. where the locator is an IDREF, a urefnode to the thing
itself.  So class ENDPOINT needs a LOCATOR property, value from a set
of classes for the different locator languages, and a (urefnode)
SOURCE property, pointing back to the ELEMENT node that gave it birth.

If this is right, it means that conforming XML processors do NOT have
to be capable of implementing most of the locator languages we bless,
although the ability to do so will clearly make them more attractive
to application developers.

5) I've redone the picture that goes with my partial redraft, and
fixed a few things, see the URL below again, good luck getting
Netscape to reload the image!

     http://www.cogsci.ed.ac.uk/~ht/new-xhl.html

ht

Received on Thursday, 13 February 1997 06:48:42 UTC