Re: Anchor terminology

[Peter Flynn:]

| I agree fully that it is high time we reclaimed some of the remoter
| linguistic vagrancies of HyTime, and that we need to do so in a
| language understanded of the people. My problem is that users tend to
| think of links in terms of direction, whether or not any
| directionality is implied: so "link end" still retains connotations of
| "target" and anchor retains connotations of "source".

Well, connotation is in the mind of the beholder, I guess.  "Anchor"
started out with a directional connotation (although I think with some
historical investigation you might find some people who thought that
"anchor" meant "source" rather than "target"), but the vernacular
usage fostered by HTML calls both ends "anchors".  <A HREF> is on one
end and <A NAME> is on the other, and they are both <A> (anchor)
elements.

Before the last few days of discussion, I might have agreed with you
that there is a slight directional flavor to "link end", but now that
I think of the ilink as the generic form from which clinks are
derived, the only directionality that seems to inhere in the term
"link end" (as a proposed replacement for what HyTime calls an anchor)
is downward, i.e., from an ilink hovering out in hyperspace to all the
thingies that it's addressing.  Depending on how the relationships
constituting the link are defined, some of those ends may have
directional relationships with regard to other ends, but I don't feel
that a specific direction is implied by the term "end" in itself.

If I dropped a colander full of cooked spaghetti on the floor and was
asked to provide the correct English word for the extremities of the
mess, I would call them "ends", with no directionality implied except
for a general feeling of movement from the center to the edges.

The test for me is how comfortable I would feel using the term in
various cases:

"This <A> link has two ends; this end is the source and this end is
the target."

"This <XREF> link has multiple ends; one end is the XREF element
itself, and the other ends are a group of things that it refers to."

"This <MORIARTY> link is an independent link with a number of link
ends that bear various relationships to each other; these
relationships are defined by the attributes on the link."

These all work for me.

| The point about an anchor is that it is something that stays fixed
| while you do something else like go ashore.

Exactly.  That's the connotation that I want to build on.  Anchors as
presently defined in HyTime don't have this quality; I could be
looking at something that is not an anchor one second and becomes an
anchor in the next one because someone in Tasmania has just completed
a document containing a link to it.  I'm much more comfortable saying
that the thing has just become a link end than saying that it has just
become an anchor.

I suspect that people learning the terminology would often confuse
"link end" with "anchor", but in the beginning this would be harmless,
because all of the link ends a beginner would work with would, in
fact, be anchors, i.e., elements that are embedded in documents
specifically to serve as link ends.  Only in advanced applications
where link ends bear no identifying marks or scars would there be a
real distinction between link ends and anchors, and at that point the
difference in terminology would serve the purpose of making the
student aware of the distinction.

Jon

Received on Thursday, 26 December 1996 13:17:42 UTC