Joe English wrote:
> Applications can be updated to treat "cheese" just like "x-cheese"
> once "cheese" becomes standardized fairly easily, but what if
> you have a huge collection of documents that use "x-cheese"?
If it worked the other way, and you had lots of documents with "cheese"
in them, and you the meaning of "cheese" ended up being Mocrosoft's and
not Netscape's (or the other way round), you'd have documents with something
incorrect in them and no way of knowing it.
It's like using a formal SGML public identifier with a + at the start before
you have registered it, in case you register it one day... and then finding
that when you register it, you register a different version.... oops.
> I see this as more of a namespace management problem than an
> standardized/experimental identification problem -- we want to
> avoid the situation where an author uses a link relation name
> that later gets standardized to mean something unexpected.
Yes. Hence the X-
[...]
> How does this sound:
> Authors may use any names they wish for REL and REV attribute
> values (without the X- convention); the namespace by default
> belongs to the author. In order to use a standardized link
> relation or set of link relations, the document must include a
> support declaration in a processing instruction in the document
> prolog or <HEAD> element. Browsers must not give special
> treatment to any link relation if the corresponding support
> declaration does not appear.
I am reluctant to suggest requiring that browsers support new kinds
of SGML markup. Although, I like the idea of
<?IETF-LINK Cheese URI http://www.w3.org/linktypes/semantics/cheese.java>
> For example, assume that a set of navigational link relations
> named "NAVLINKS" has been published which defines behaviour
> for the link relations NEXT, PREVIOUS, UP, TOP, CONTENTS, and
> INDEX.
I suppose you could do
<HEAD>
<LINKSET HREF=".....">
<LINKSET HREF="......">
<LINK REL=.... HREF=....>
<LINK LINKSET=.... REL=..... HREF=.....>
</HEAD>
but I think this is more complex than necessary.
The idea of sets of link semantics that can be associated
with a URI _does_ seem sound to me. I'd rather do it without ProcInsts if
we can.
lee