Re: anchor awareness (was Re: Richer & richer semantics?)

(Eliot Kimber:)

> To relate this to HTML, the A element is a hyperlink when the HREF
> attribute is used.  It is a "contextual link" because it is also one of its
> own anchors.

What Eliot said.  I should have clarified in my response that in
HyTime a link may or may not be one of its own anchors, but in HTML it
is *always* one of its own anchors.  A maximally "independent" link
expresses a relationship in which it does not itself participate.
This seems a bizarre concept to many people whose only experience with
hypertext is HTML, but it is commonplace in the representation of
relations in databases, for example.

> I think Steve might be asking about three things:
> 
> 1. Should we allow completely independent links (unilateral addressing of
>    all anchors of a link).  If we disallow it, then at least one anchor
>    of every link will know it's an anchor because the link is always one
>    of it's own anchors.  I think we're all agreed that we need independent
>    links.

If such agreement exists, it's news to me, but I welcome it.
(However, I can't believe that I could have missed the necessary
discussion of the awesome implications of such a decision, yea or
nay.)

> 2. Should the elements always indicate, in their syntactic representation,
>    that they are anchors (e.g., an attribute called "anchored-by" that
>    lists the addresses of those things that point at it).  This could be
>    reasonable in a tightly-controlled, closed system of documents, but
>    is probably not reasonable or possible in a Web environment and I doubt
>    that anyone would seriously propose it.

I was certainly not proposing this.

> 3. Should the *methods* associated with objects *always* be informed when
>    they are addressed as an anchor?

I wasn't proposing an algorithm either, but this is closer to the
mark.  What you propose is a way for applications to implement anchor
awareness, and that *is* what I'm talking about.

>    This is a bit more subtle, because
>    it can be difficult or impossible to do this in all environments (e.g.,
>    when the anchors are addressed by a query against the entire Web).

One of the problems with implementing anchor awareness is how to limit
the number of links whose anchors the application is responsible for
knowing about.  HyTime's "bounded object set" notion is one way to do
that.  It's obviously impossible for any application to be aware of
all the anchors of all the links that exist on the Web.

>    In other words, in the general case its useful or necessary to defer
>    resolving some anchor addresses until the anchor is traversed to (or
>    access to the anchor is otherwise requested).  This means that there 
>    will always be anchors that do not know they are anchors at the time
>    link is created, only at the time an attempt is made to address the
>    anchor.

> The data represented by XML documents is dead and lifeless--it is just
> data.  But there are always presumably processing methods associated with
> the data--browser styles, retrieval methods, whatever.  Thus there will
> always be *something* that is "responsible" for the data objects and could
> potentially be informed about their anchor status.  These methods might be
> specialized link management systems, e.g., HyTime engines, Xanadu systems,
> Hyper-G servers, etc.
> ["Dynamic" or "active" documents are, I presume, documents where the
> methods for certain data objects are tightly bound to the data object,
> e.g., a 
> script embedded in an HTML document.  However, such documents are no more
> or less active than documents to which the equivalent function is applied
> by external methods--in fact I'd argue they're *less* dynamic because the
> tight binding tends to limit you to only one possible behavior, instead of
> an infinity of possible behaviors.]

Yes, yes, yes, yes.

> Note that in the HyTime model where you have a HyTime engine, the method
> for any object can always interrogate the HyTime semantic grove to
> determine if the object is an anchor, because the HyTime semantic grove is
> where the information about all the links it is managing is maintained.
> Thus you should expect any general-purpose HyTime engine to have an
> "anchored-by?" function that will return a list of either all the links of
> which the object is an anchor.  Given that list of links, you can then ask
> the HyTime engine about the other anchors of those links. [And note that
> since the HyTime semantic grove is a grove, it can be interrogated by DSSSL
> styles and transforms using normal DSSSL functions, so there's an obvious
> path to using DSSSL to apply presentation and/or behavior to HyTime-managed
> hyperlinks.  Groves are so cool.]

Yes, yes, yes, yes.  (I'd like to point out that I used the word
"cool" to describe groves, at least in this thread, *before* Eliot
did.  But I admit I probably heard him say it out loud earlier still.
Truly, groves are cool.)

> This is essentially what systems like Hyper-G/HyperWave or Xanadu do:
> maintain a database of what is linked to what.  HyTime just defines a
> specific data model and some base semantics for it.  No magic here, just
> standardization of typical practice (I'm not sure there's a enough
> concensus to say "standard practice").

I would say there's appreciable consensus about the grove paradigm.
SP does it, JADE does it, MarkMinder does it, and the next version of
HyMinder is about to do it.  Three international standards do it, and
a fourth (SGML itself) will undoubtedly do it next year.  (Come to
think of it, Fujitsu Labs put a layer over old HyMinder in order to do
DSSSL with it.)  Alex Milowski is doing it.  Several topflight people
are talking about doing it.  If you already have groves, it would be
ridiculous to do any kind of hyperlinking without using the grove
paradigm.  If we assume the use of groves and property sets for
expressing the object model of XML documents, the anchor awareness
question becomes "merely" one of how elaborate the relationships
involved in hyperlinking should be.

I was asking the question from the other angle, assuming that we have
NOT yet decided to use the grove paradigm for XML.  Without groves,
anchor awareness is a huge headache.  I think a decision to do anchor
awareness pretty much necessitates moving to the grove paradigm.

(Lest there be any doubt in anyone's mind, I think moving to the grove
paradigm is a good idea in any case.  That still leaves the question
of anchor awareness open, however.)


--Steve

             Steven R. Newcomb   President
         voice +1 716 271 0796   TechnoTeacher, Inc.
           fax +1 716 271 0129   (courier: 23-2 Clover Park,
      Internet: srn@techno.com    Rochester NY 14618)
           FTP: ftp.techno.com   P.O. Box 23795
    WWW: http://www.techno.com   Rochester, NY 14692-3795 USA

Received on Sunday, 22 December 1996 16:23:08 UTC