Crosses grow Anchors; Bear, as thou shouldst do
Thy Crosse, and that Crosse grows an Anchor too.
But he that makes our Crosses Anchors thus,
Is Christ, who there is crucifi'd for us.
Yet may I, with this, my first Serpents hold,
God gives new blessings, and yet leaves the old;
The Serpent, may, as wise, my pattern be....
-- John Donne
The conclusion I draw from the recent discussion of HyTime versus
vernacular usages of the word "anchor" is that we would do well in
this case to respect the vernacular.
While I think that HyTime provides a very useful basis upon which to
begin our discussion of linking, I don't think that we are constrained
to use its sometimes obscure wording in forming our own specification.
We can use HyTime-compatible syntax without using HyTime terminology.
In particular, we can, as speakers of English, reclaim the term "link
end" to mean what it should have meant in the first place and what any
speaker of English would naturally think it means: one of the ends of
Therefore, I propose the following basic definitions:
Link: An element that expresses one or more relationships between
Link end: One of the objects addressed by a link.
Anchor: An element designed to serve as a link end.
Under these definitions, what HyTime generically and confusingly calls
an anchor (that is, anything that is addressed by some link somewhere)
is unambiguously called a link end, putting the emphasis on the role
of the link in determining whether something is, in fact, a link end,
and anything that has been deliberately formed in such a way as to
make it easy to link to (as, for example, an element to which an
identifier has been assigned) is called what everyone who is not a
HyTime expert would call it, viz., an anchor.
I understand that this terminology will give megrims to every HyTime
expert in the world. What I'm suggesting is that all ten of them can
put up with the pain in the interest of creating a less rebarbative
terminology for the teeming millions.
Think of it as a Christmas present.