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

(Tim Bray:)

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

I don't understand how proposition 2 follows.  First of all, the fact
that we know something (for example, the fact that something serves as
the anchor of a link that is elsewhere) doesn't require us to act on
that knowledge.  Secondly, there is no requirement that we regard HTML
links as bidirectional.  It would be silly to do so in most cases, I
think, because they were written without such an intent.  It would be
as asinine as refusing to watch "Casablanca" in black and white,
simply because a so-called "colorized" version now exists.  And just
because I have a color TV doesn't mean I can't see black and white
films on it.  In other words, the fact that XML applications could
"know" the anchor status of every object does not preclude their
emulating HTML applications by behaving as if they did not know the
anchor status of the remote anchors of HTML links.

> 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

I don't see how this question is open to debate.  If none of the
anchors knows that traversal is possible, for example, there is no
point in having a traversible link, because no traversal will ever be
possible.  There must, therefore, always be at least one anchor that
knows that it is an anchor of a link, so that the link can be examined
and the other anchors discovered, so, in turn, traversal can be
initiated to those other anchors.

> 2. the benefits of self-awareness depend on an ability to state with 
>    confidence that all anchors are self-aware, so

It depends which benefits we're talking about, but, in general, yes.

> 3. there seems no particular benefit to forbidding what Eliot calls
>    "completely independent" links.

Huh?  Your point, and the logical connections between your
propositions, all totally elude me.  Sorry.  Please try again.

Taken at face value, though, I disagree with proposition 3.  The
benefit of forbidding completely independent links is that you need
never face a situation in which at least one anchor must be aware of
its anchor status even when the link that confers that status is
elsewhere.  It's a reasonable and very defensible position.

> 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

I would rather say that current web links have fixed types and fixed
anchor roles (although the roles are not explicit).  The type and
roles are made explicit in the HTML spec, but the roles are not
given names using HyTime syntax, obviously.

Current web links are two-ended.  I am having trouble understanding
what purpose a single-ended link might possibly have, and so the sense
what you are saying again eludes me.  (*frustration*) (I don't know
what "a completely opaque query" is, either.  Sorry.)

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

Maybe you're right.  I don't know; I haven't considered this
possibility.  At first blush, though, I tend to think the "greater
utility" may be much less than "substantial".  Can you think of any
examples?

> Probe 4:
> 
> 1. Enforcing anchor-awareness is not done in terms of syntax, but in
>    terms of allowed behavior during link traversal, so
     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I would agree with this statement if it said "...terms of required
behavior in support of, e.g., 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.

Yes.

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

You haven't supported this conclusion by showing how (or even whether)
these benefits are any greater than the benefits offered by HTML
links.  But, maybe HTML-style links are sufficient.  If you're saying
that HTML linking functionality is sufficient for XML, then you should
say so explicitly.  If that conclusion is the consensus, then I will
be content; my request for a decision will have been satisfied.

> 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

Too easy.  You're confounding the question of whether systems can
enforce the terms of licensing agreements (they can't), with the
question of whether technical means can be used to associate legal
notices regarding the terms of licensing agreements (they certainly
can).

> (b) this semantic [publish and let anyone point to it anonymously] is
>     something that is actively desired by many people.

Of course.  I'm certainly not proposing that we should do away with
the semantics and capabilities of HTML links.  Far from it.  The
question I'm asking is whether we should do more than that.

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

But what is the purpose of linking metadata to something if, from the
perspective of that something, we don't know that such linking is
going on?  How do we retrieve such metadata?  How do we know that
there is metadata to be retrieved?  As far as I can see, the only
possible answer is: We can know this and retrieve the metadata if and
only if our something is aware that it is the anchor of the link that
specifies the association between the something and the metadata.  It
is NOT easy to achieve a situation in which new links can be created
whose traversal-initiation anchors must be in read-only documents.

(Also, what do you mean by "multidimensionality"?  I'm stuck again,
unable to figure out what "dimensions" have to do with this
discussion.  Sorry, Tim.  Please be patient with me and try again.
Do you perhaps mean "links with more than two anchors"?)

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

I don't get this question either.  What on earth would be the point of
refusing to retrieve something that, from its own perspective (a
perspective you don't have unless you're already there, which you're
not if you're trying to retrieve it) doesn't know that it's an anchor
of the thing which is where you already are?

In any case, no, such refusal would not deliver the benefits that
I'm discussing.

(Unless maybe I don't know what a "gateway" is.)

Tim, at least one of us is definitely not understanding the other's
thinking.  I used to think it was just *you* who was not understanding
*me*.  I am now so boggled by your probe questions that I suspect it's
both of us, or at least I.

Can anybody help us out?  I think the ox is in the ditch over here.


--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 23:53:47 UTC