Re: Radical cure for BOS confusion

At 11:04 PM 1/6/97 -0800, Jon Bosak wrote:
>I sense that a lot of complexity arises from the fact that the ilinks
>that have something to do with a document can be located at arbitrary
>places inside the document, at arbitrary places inside some other
>document(s), or some combination of the two.  If ilinks are allowed
>only in special ilink collections, and if all the ilinks that the
>author wishes to associate with the document are specified at a
>particular place in the document, then I believe that life gets much
>simpler for the implementor.  (Implementors please confirm or deny.)
>I *know* that life gets much simpler for the author and for the person
>trying to teach that author, because now link functionality falls
>neatly into two stages: the beginner stage that learns how to put
>alinks in documents and the advanced stage that learns how to
>construct and maintain linksets independent of "the real document
>content" (the part below the "linkset headers").

One of the (traditional) difficulties in implementing ilinks is based on the
fact that any of it's anchors may be in various other documents, some
parsed, some not.  If link processing can be isolated such that it is either
guaranteed to be done before or after the parsing of all of it's relavent
target documents, it becomes much easier.  If it is parsed first than a
basic constraint net can be built and it should be possible to determine if
the current element with little extra work (assuming all tree traversal
locators work in the direction of the parse, ie. this partially fails if you
can talk about the previous sibling of an element).  If the ilinks are
processed after all the target documents, then some representation of the
documents must be kept around so they can be randomly traversed.  This used
to be considered too expensive, but is required to support DSSSL anyway so
this isn't so bad anymore.


On a different note, if the ilink document's DTD is too impoverished for
some, they could used alink to link to a seperate document with further info
(not an optimal solution).  While this is cludgy with generic tools, it is
easy if the (authoring) tools are designed with this in mind, and then you
keep your simple ilink document type as a commonly understood base.
(Actually, this starts to sound like using hyperlinks to implement
inheritance relationships.  *shudder*) Architectures could do a similar
thing.  If a standard DTD is required for XML imling documents, then maybe
Architectures should be explicitly mentioned as a way implementors could let
the authors modify the DTD for their own purposes but still allow generic
applications to understand their DTD's (as an Architecture derived from the
simple ilink dtd).


On a third note, in the recent past a number of people have hinted to moving
some of the hyperlink info into the style-sheet (or a style-sheet).  I just
want to point out that not all hyperlinks necessarily exist for human
traversal.  I can think of a number of cases where I might be sending XML
documents between (remote) processes and want to use hyperlinks to express
information relationships, where this data is never directly presented to
the user.

-derek
"that which is not slightly distorted lacks sensible appeal: from which it
follows
 that irregularity - that is to say, the unexpected, surprise, and astonishment,
    are an essential part and characteristic of beauty" - Charles Baudelaire

Received on Thursday, 9 January 1997 12:02:51 UTC