clink/ilink direction (Was: anchor awareness)

I've been trying to assimilate the last few days of discussion on the
question originally raised by Steve Newcomb:

| "Does an anchor know that it is an anchor?"

My first conclusion is that this is an unfortunate way to phrase the
question (sorry, Steve).  If I understand correctly, no HyTime anchor
can be assumed to be self-aware even in the metaphorical sense because
in the general case there may be nothing attached to the anchor to
identify it as such.  If a link addresses an unmarked span of
characters somewhere in hyperspace then *something* is aware that the
span is a HyTime anchor, but that something is surely not the unmarked
character string but rather a HyTime application.  If we are to
attribute awareness in a metaphorical sense to something other than a
program, then that awareness must belong to the link itself, not to
the things it's addressing.  So I suggest that we drop the whole
self-awareness trope; it just gets in the way.

If I ignore the issues that seem to have been created by this
metaphor, and I ignore the other issues that seem to have been created
by HyTime's idiosyncratic use of the word "anchor", then what stands
out for me in this discussion is this statement by Steve:

| 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.

A little later, in replying to a couple of questions from Tim Bray,
Eliot Kimber amplified on this by saying

| [I]t's important when discussing these issues to distinguish
| scenarios where the system is closed or mostly closed (as in
| Hyper-G) or is completely open (as in the general Internet Web
| case).  I personally think XML's greatest benefit will be in
| Intranets, where it is potentially possible to manage all the
| links and know all the anchors (at least those not addressed by
| pathalogical queries).  Certainly within Internets there will be
| significant information management and analysis benefit to being
| able to apply new webs of links to existing documents (imagine an
| MS Project schedule as a web of hyperlinks anchored to a
| time-based coordinate space).
| 
| [...] If you want to make the link available to the Internet
| masses, at least one anchor must be completely and irrevocably
| self aware, i.e., the link must be one of its own anchors (a
| "contextual link" in HyTime terms).  When you are in an Intranet
| environment, it need not be.

What I'm hearing -- please correct me if I'm wrong -- is that we can
implement contextual links for the open case (the Internet as a
whole), thus modestly but usefully expanding the range of capabilities
of the HTML <A HREF>, and then we have the further option of defining
independent links that will work only in closed environments, AKA
intranets.  (Eliot goes on to suggest a method for wrapping an
"invisible linking element architectural form" around anchors to
"enable the conversion of independent links into contextual ones", but
pending a fuller description, this sounds over-engineered to me.)

A third option that doesn't seem to have been discussed much is that
we can define ilinks whose scope is the same as the SGML ID space, or
to put it loosely, ilinks that are used in the same document in which
they are defined.  I'm not sure how useful this would be.

If we set aside the last possibility and Eliot's invisible wrapper
scheme, then what we seem to be left with is a clear reason to define
a contextual link mechanism for general Internet use in our first link
specification document and a possible case to be made for defining an
independent link mechanism for intranets that we may want to put in a
first link specification document or may want to defer for a later
version.

Is that right?

Jon

Received on Wednesday, 25 December 1996 23:54:48 UTC