> [Joe English writes:]
> OK; fine by me. So there is exactly *one* reserved link
> relation name, namely LINKREL, and authors can use any
> other name without worrying about unexpected behaviour
> unless they explicitly request it by specifying a link
> with relation LINKREL and an HREF which points to an object
> specifying a set of semantics for a particular set of
> link relation names.
Of course, this doesn't handle the case where one adds a keyword to
a set of semantics.
There is no general solution to this that I can see, apart from suggesting
that people include a version number in the URL, whether using the widely
unimplemented (?) ";version=1.3" syntax or whether putting the version into
the URL, or, later, using a URN, or otherwise using a different URI when
the contents change.
I don't have strong feelings about this, except that it is much better
than putting a PI in betwen <HTML> and <HEAD> -- and with the usual lack
of a DOCTYPE declaraion in HTML files, there probably isn't anywhere
else it can go, since after <HEAD> is clearly too late.
I think I prefer a new and separate attribute, because then one can
give Anchors a link role as well as LINKs in the HEADer, and can override
the link nameset on a per-anchor basis.
Having said that, I am also thinking about how to write the spec for
HoTMetaL, which doesn't have any HTTP support and doesn't itself follow
URLs at all. In many cases, it can't, as a lot of people use it on
stand-alone systems and copy files to the WWW server later -- e.g. a
portable PC.
This means that we'll end up hard-wiring the link set and the
link terms that are special, or at least put them in a config file,
for a pop-up list.
I suppose this is no worse than if the links to the semantics were
not there.
If we follow this route, though, I think we *must* define what is at
the other end of the URL, so that software can at least determine
automatically what the keywords are and where they came from, can
flag incorrect ones, warn about multiple (possibly conflicting) cheeses,
offer users a choice of keywords to insert, and possibly display only
links of a certain type in a visualiser.
One way to do this would be to have the other end contain a list of anchors,
each with a REV tag for the keyword they are defining, and optionally
pointing to an actual definition, e.g. JAVA code.
Obviously an actual browser would not do all this indirection, or even
Netscape would need to get their graphics designers to change the hourglass
icon to a calendar icon :-)
If I were less tir'd I'd try to discuss why & whether all this indirection
is actually useful, and to whom. I still think we have not seen a good,
practical, down-to-earth justification for changing Tim's original scheme.
That doesn't mean that there isn't one. It means that I think the
theoretical reasons are not strong enough, as there are pragmatic counter-
arguments for them.
Lee