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

I think we are making progress here.

It seems obvious from Steve & Eliot's remarks that we might as well adopt
the Hytime nomenclature and define "anchor" to be something that is 
actually participating in a link relationship.  It's easy to explain and
understand, and is totally unambiguous; definitely in the XML style.  (And
web-head friendly; an HTML anchor *is* in fact an anchor when it's being
used; the fact that it's not when it's not doesn't really muddy the waters).

A thousand words or so later, I *think* I understand Steve's question; but
let's have another go-round to make sure.  I think I'm not that untypical of 
the SGML- and Net- savvy people on this bus who are struggling with these 
questions, so I don't feel guilty at all about going around and around on 
this until the message gets through at least one thick skull (mine).  If 
these issues are self-evident to everyone else but me, holler and I'll shut 
up.

Let's launch some unmanned probes here, and if (as seems likely) any of
them go completely off the rails, one of the experts can step in and
say where.

Probe 1:

1. Web links contain lots of ends that don't know they are anchors, thus
2. if we require all anchors to be self-aware, we won't be able to subsume 
   the current Web mechanisms.

Probe 2:

1. If we support N-way links with some anchors not being self-aware,
   there remains the question of whether we require *one* end to be
   self-aware, but
2. the benefits of self-awareness depend on an ability to state with 
   confidence that all anchors are self-aware, so
3. there seems no particular benefit to forbidding what Eliot calls
   "completely independent" links.

Probe 3:

1. Current web links are untyped, un-roled (in fact carry no metadata),
   and are either single-ended or are a completely opaque query, whereas
2. HyTime ilinks (OK, HyLinks real soon now) are multi-way and have
   several useful places to encode what I think of as per-link or 
   per-anchor or per-role metadata, so 
3. on the surface it seems that an ilink, even if it involved all sorts
   of non-self-aware anchors, would offer substantially greater utility
   and flexibility than what the Web offers.

Probe 4:

1. Enforcing anchor-awareness is not done in terms of syntax, but in
   terms of allowed behavior during link traversal, so
2. The spec we're about to write would need to specify, not just
   a language, but processor behavior, just as the XML spec does.

*If* I've understood the issues, I think I'm ready to take a position:
no, we should not require universal anchor-awareness, because it's
hard, and we can deliver significant benefits without it.  Also, as a
hypertext-theory-challenged web-head, I have derived significant benefit
from pointing freely at lots of other people's stuff; while I acknowledge
that this creates problems in the area of intellectual property and so on

(a) it seems unlikely that these problems are amenable to a technical
    solution, and
(b) this semantic [publish and let anyone point to it anonymously] is
    something that is actively desired by many people.

If Steve and I have a disagreement here, it seems to be crystallized in
the following:

Steve: 
>What's the
>use of ilink if none of the anchors know that they are linked?  After
>all, an ilink is nothing more or less than a link whose own location
>can be different from [Independent of] the locations of *all* of its
>anchors.

To which I'd answer; the use is that of the existing Web mechanisms,
only made multidimensional, and with a place for metadata, and applicable
to read-only media.  The usefulness of the existing Web mechanisms is not 
open to realistic challenge; and multidimensionality and metadata seem, on 
the face of it, to be major steps forward.  And easy to achieve.

Follow-on questions... *if* we specify some self-aware anchor machinery, 
*and* we define behaviors for an XML processor for accessing these things, 
then:

a) could an XML processor, by offering an anchor-retrieval mode that
   refuses to retrieve anything not self-aware in the approved way, 
   act as a gateway that would deliver the benefits that Steve is 
   discussing?
b) could such machinery and behavior be described simply and compactly,
   with a degree of difficulty not greater than that of the XML spec?

Sorry for the long-windedness.

Cheers, Tim Bray
tbray@textuality.com http://www.textuality.com/ +1-604-488-1167

Received on Sunday, 22 December 1996 21:51:31 UTC