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

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

        Eve

Received on Tuesday, 28 January 1997 12:44:32 UTC