Re: Anchor terminology

At 10:44 AM 1/28/97 +0000, Peter Flynn wrote:
>> (1) the basket that the pointy bits go in
>> (2) the pointy bits that point at things
>> (3) the things the pointy bits point at
>> How about "link", "pointer", and "target".
>That's the clearest explanation so far, facetious or not. The problem
>we seem to face is that while _we_ can discuss this using (for example)
>HyTime terminology, once we [re]enter the Real World [tm], we are going
>to have to document this in terms that implementors and authors can
>grasp easily, and that means link, pointer, and target. We are also
>going to have to deal with the use of words like "source" and
>"destination", as users will persist for some time in conceiving of
>links as unidirectional:

"Link" is fine (the only word we all seem to have settled on :-).

"Pointer" is fine, too, though "address" might be better: Is a pointer
potentially made of a chain or relative addresses, or is an address made of
a chain of relative pointers?

"Target" tends to imply directionality, and it seems useful to have a term
for "link ends" that has no such implication.  Then you can use "source"
and "target" (or "destination") to define such terms as
"bi/multi-directionality," and to discuss link traversal behavior
intelligently.  I'm not crazy about "link ends" because it sounds weird to
talk about "source/starting/jumping-off *ends*," but everything else I can
come up with is just as weak: "link locations," "link points," "linked-to
places"...  Sigh -- maybe "target" is best.

>Personally I'd like to avoid the use of the word "anchor" altogether,
>in documenting or publicising XML: it simply is not easily explainable
>to the author or user. Anchors are things that stop ships going adrift,
>and the only possible explanation in discussing hypertext linking is to
>say that an anchor is the {pointer|start-point|source|beginning|jump-off} 
>of a link that holds the world steady while you follow (not "traverse",
>please) the link to somewhere else: the clear implication being that
>while the anchor holds, you can follow the link back again to where you
>started. That's too much for many people to swallow: pointer is clearer.
>"Double-ended pointer" is even clearer when we come to demonstrate

(Not to mention the fact that HTML's <A NAME=> breaks this proper sense of
"anchor.") I agree with avoiding the scarlet letter.  Do we even need to
have a term for elements that are explicitly supposed to be link ends?  Can
we just call them "link end elements" (or whatever we settle on for
directionless targets)?