locating capabilities vs. anchor awareness

Hyperlinking and locating anchors and anchor awareness is all quite easy if
the only mechanism for locating is ENTITY and IDREF.  A number of people
have expressed interest in using the TEI style linking (having never used
seen TEI, that is difficult for me to evaluate.  Anyone have a good
reference for me where I could get some info/examples of TEI locators?).
Another group (largely composed of HyTime TC1 editors no less) is carrying
the HyTime torch.  For this to succeed I believe that either one side needs
to give in (and I pity the TEI people if they try to get the HyTime people
to abandon HyTime) or some general mechanism needs to subsume both somehow.

How difficult the anchor awareness problem is depends on the richness of the
locator model intended to be used.  David (and others) requested the ability
to locate data which has no ID.  How far do people want this to go?  A full
query model a.k.a. HyTime, where anything can be located and if HyTime can't
then you just use an external handler with QueryLoc (which used to be
NotLoc, for "Notational locator").

If a simple static locator model is used it greatly simlifies the process of
problem of determining anchor awareness (talking as someone who has
approched this from an implimentation angle).  If general locators are used,
allong the lines of HyTime's nameloc, treeloc, etc, do you allow document A
to use document B's locators?  This gets to be a messy situation (which is
why I broke it out to a seperate level in my previous post about resolution
levels),a nd can be difficult to implement, and costly to do in a general
way (costly in terms of programmer time, cpu time, UI time/complexity,
document complexity, etc).

Much as I must agree with Steve and Eliot that the HyTime/DSSSL grove
concept is "cool" (I was part of it's development, I hope I think it is
cool...), I think that it is too much for what we are trying to do
_right_now_.  If we want a full model, then we should just use TEI or HyTime.

So the question is, how much do people really demand?  What can we trim?
independent links apprears to be in the "in" box, but what about locating
mechanisms.  I have seen/heard almost no discussion regarding what
capabilities people want (other than requests not to be limited by IDREF).
The answer to this questoin is crutial to the answering Steven's questions.
(None of which are easy.  He an I have spent long hours "discussing" some of
these issues to the point of sending the rest of the office into hiding.)

I might propose as some starting requirements:
        - IDREF (obviously)
        - ENTITY (what does this really mean?)
        - inter-document IDREF (i.e. refering to an ID in a different document)
        - sub-element tree traversal (avoid the whole issue raised before
                over pseudo-elements messing the traversal by exlicitly
                ignoring them)
        - content (linking to the content of an element... but what does this
                mean? are subelements content?)

I specifically avoided any attempt to do general, or complex queries. keep
to the KISS method of design, for simpler explanation and implimentation.

Anther questin is how should the locating mechanisms tie into the Linking
mechanisms?  Are they treated as one and the same, or is locating seperated,
as in HyTime?

-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 Monday, 23 December 1996 15:32:42 UTC