Re: Radical cure for BOS confusion

At 03:04 PM 1/10/97 -0500, Steven J. DeRose wrote:
>At 08:57 AM 01/09/97 -0800, Derek Denny-Brown wrote:
>>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
>
>What if we simplified HyTime location ladders by insisting on the convention
>that in XML-LINK documents, all ilinks and all of their subordinate rungs
>must be together in a reserved header element (I don't care whether we
>reserve a GI or just an architectural form name in this case). Then you
>don't have to parse entire documents just to get their ilinks, and you can
>simplify/accelerate your implementation a tiny bit by knowing where to look
>for some things.

That is not the issue I was worried/concerned about.  One reason contextual
links (html's <A>, TEI <XREF> & <XPTR>) are the primary hyperlink style
implimented in today's software is that it is very easy to figure out what
the start for the hyperlink is, trivial even.  Using contextual links, you
only need to traverse the document when the user explicitly asks for it, and
thus a small delay is acceptable.  Using ilink style links means that the
document load also incurs a similar penalty _for_every_ilink_ just to figure
out what parts of the document are anchors.  The BOS defines which documents
must be processed to ensure that all anchors have been located.  As an
simple example, if you have three documents, A, B, C, where you are loading
document A, but B and C are in A's BOS, then all three documents must be
processed in order to determine what parts of A are anchors.  This is one of
the reasons HyTime has not already replaced HTML.  As Steven Newcomb is fond
of saying, how does an anchor "know" it is an anchor?  In order to answer
that question, every thing that _might_ point at it must be resolved and
_all_ ilinks must be processed to determine if _any_ use that object as an
anchor.

I like ilinks, but having worked on developing software to implement HyTime,
they are not easy.  Carefull restrictions should be made to reduce overhead.
One possibility is to require a XML Hyperlinking processor to inform the
application of anchors _only_ if the hyperlink is declared in that same
document.  hyperlinks can use external resources to locate destination
anchors, but it is not the responsibility of the hyperlink processor to keep
track of those anchors other than to know how to resolve it on request.
Going back to Steven Newcomb's terminology (sorry, but having working with
him, I fear his HyTime terminology has made a perminent dent in my psyche),
an anchor only knows if it is an anchor when the link of which it is an
anchor is declared in that same document.

I thin I just managed to say the exact same thing twice, so I'll try again,
as a proposal:

A XML Hyperlinking processor should ("is required"?) to notify the
application of all anchors of hyperlinks only if the anchor and the
hyperlink are declared in teh same XML document.  External resurces, as
provided-by/restricted-by the BOS (and any other constraining mechanism we
choose to define), may be used to locate the anchor.

The problem with the above proposal is that it breaks the usefulness of
ilinks for annotations.  I am not very happy about this, and would be happy
to hear a better solution.  I worry that a XML hyperlink processor will need
to keep a complete representation of every document in the BOS around
because any part of the BOS might use some other part as an anchor.  Another
possibility is to define the BOS as a ordered list of documents such that if
a hyperlink processor where to process the documents in order it would not
need to report anchors (though it should report a path to the anchor) which
are located in documents earlier in the ordered list of documents (which is
the BOS).  Thus, once a document is processed, the hyperlink processor only
needs to keep around some representation of locator/addressing elements
which might be used by later documents.  Hyperlinks and anchors in the
earlier documents will have already been passed to the application (or
stored somehow) and are not neccessary for the hyperlink processor to
process the later documents.

*David* since you were the one who responded to my previous post, does this
at least make sense to you?  Have I explained why I want to restrict the
power of ilinks?

-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 Friday, 10 January 1997 20:16:27 UTC