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

Tim writes:
> 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).

I'd feel happier documenting or teaching this if there was a phrase in
there to explain that "anchor" in XML is no longer restricted to the old
HTML sense of "jumping-off-point". Many millions of users have been taught
(or have assimilated) that an anchor is a location you can return to using 
the BACK button (and I'm as guilty of this as anyone else because it's a
quick and easy way to get the unidirectional dea across).

Probe 1: fine. Probe 2:

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

Is this a binary choice, or do we have some growing list of benefits
as the number of self-aware anchors grows (n --> N) ?

Probe 3: fine. 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 this means binding a set of behaviours to (say) a specific set of
element-and-attribute combos by prescription in the spec, then I don't
see a problem. If it means "may" and "might" and "could" then I'm less
happy about it, as we would make it easier to lose Probe 2.2 above.

I think we need to be very explicit about the benefits that are achievable.
If we can't spell them out in the spec (that may not be the right place
for them) then we should have an Implementor's Notes document which does.

IPR:
> (a) it seems unlikely that these problems are amenable to a technical
>     solution,

They can be solved at the technical level but require high-level 
enforcement (ie obeyable legislation).

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

I think that on the current Web "many" == "most". If there is a danger
that people will equate XML with "you can't just point at anything any
more" then there is a risk it will be ignored. Terry's arguments have
convinced me that we do after all need to cover the IPR topic in the
spec, but I don't know to what depth.

///Peter

Received on Monday, 23 December 1996 05:43:36 UTC