Re: clink/ilink direction (Was: anchor awareness)

At 9:07 AM 12/27/96, Jon Bosak wrote:
>I think that there is general agreement that ilinks are highly
>desirable.  The question is whether enabling ilinks requires the
>application to know the entire grove, which in the general case would
>mean knowing the entire Web as a grove.  Steve and Eliot seemed to be
>saying that it would be necessary for the application to know the
>grove; you seem to be saying that it would not.

   Any method of link location must be able to address data. And if we want
to support read-only media, as we have already said, then we need to
address things without changing the document by creating explicit anchors.
Web sites not under user-control are essentially read-only media, so this
would be a requirement even if we had not already made it one.

    A "grove" is just a new name for what everyone else in the world calls
a "parse tree". Now we could avoid parse trees by using byte offsets, but
given that addressing bytes in markup does not usually make sense, we will
need to have the parse tree anyway -- that's what structural addressing is
founded on. As far as I can tell, the details of groves are irrelevant to
XML, unless we decide that we have to explain how XML linking can be
treated as HyTime linking. I think this is a fine idea, but a relatively
low priority, as HyTime implementations are a micro-niche even within the
SGML community.

>| I don't yet see any reason that ilinks should not be
>| implemented. The issue of how software should be instructed to
>| find ilinks to interpret relative to documents being processed is
>| not really our problem (except for ilinks within one of the
>| documents that they link).
>
>If I were an implementor I would say that this is handwaving.  Given
>the depths of difficulty we have glimpsed during this discussion, I
>don't think it will be very convincing to say that finding ilinks is
>not our problem.  It seems to me that finding ilinks is exactly our
>problem.

Finding ilinks is a matter of reading a document that contains ilinks. What
we cannot describe is the policiy about what documents should be read in
seraching for ilinks, or how those documents might be found. It may prove
to be useful to require some ilink mechanisms of XML link managers, for
instance (some _possible_ mechanisms we might want):

   + An XML link manager must be capable of processing several XML files
together, notifying the application of any ilink endpoints that are found
in any of the files, whose ilinks are also found in those files.

   + A user of XML linking software shall be able to create a database of
ilinks that will persist as documents are processed. Ilinks in this list
will be passed to the application when a document it addresses is
processed.

   + An architectural form <linkdb src="someurl"> shall specify an external
document whose ilinks are essential to the processing of the document
containing the linkdb. An application that provides linking behaviour
should obtain the referenced document and interpret its ilinks in relation
to the original document. [note that I _don't like this suggestion].

   + An XML link manager _must_ pass ilinks within a document to the
application, and be prepared to interpret them. (essentially require
internal links).

  The point of the list above is that there is an open set of reasonable
ways to find documents to process together: the choice of which documents
will be processed together is an application matter. But we _do_ need to
say what an ilink means, and deal with the fact XML linking engines must be
prepared to process multiple entities (whether serially or simultaneously
does not matter) in order to correctly handle ilinks. Which documents are
processed is not necessarily our concern.

   A comment on the depths of difficulty we have seen:
   Most of the difficulty seems to be understanding the HyTime model and
terminology, not the basic hypertext functionality. I think that HyTime's
tendancy to complicate the simpleis skewing the discussion. HyTime
terminology is a strange mix of de novo terms and new meanings for old
terms. But semantically, an ilink is no more complicated than a record in a
database that contains external keys. And it has the same shortcoming: you
have to "join" the ilink against a relevant document for it to be
meaningful. We need not prespecify the joins that an XML linking engine
should support, but we need to define the mechanisms to enable them.

   -- 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 Friday, 27 December 1996 16:57:48 UTC