This is *exactly* why the browser should not be left to interpret a string.
Joe 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"?
Then you have a problem. The answer is to replace the "X-..." prefix
with some more dynamic means of binding some semantics to the name(s).
I proposed that the URL/URI is the mechanism that is used now to do
this. Thus the "linkas:..." prefix.
> I see this as more of a namespace management problem than an
> standardized/experimental identification problem -- we want to
Me too. And we have a means of managing namespaces already.
> avoid the situation where an author uses a link relation name
> that later gets standardized to mean something unexpected.
> Marking link relations as experimental seems less important,
> especially for potentially long-lived documents.
I agree. The important distinction is not 'standard' vs. 'experimental',
it is 'where is this defined?'. There may in fact be many 'standards' in
use in different communities of practice. These practices will change
far more slowly than the standard.
> 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
This is the case now, but nobody has implemented REL/REV except SCO.
> 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.
In other words, they must interpret it as a default 'goto (URL)' link.
My only change to this is allow the 'support declaration' to appear
as a qualifier to the name itself, i.e. "linkas:DAIRYPRODUCTS/cheese"
> 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. Also assume that another set named "DAIRYPRODUCTS" has
> been published which defines the link relation CHEESE as
> described above.
Define 'published' ? If you mean, anonymously-ftp-able over the net,
then once again URLs/URIs are the standard means of specifying such a
published location.
> An author who wanted to use the navigational link relation set
> (but has never heard of the DAIRYPRODUCTS link relation set)
> could use:
>
> <HTML>
> <HEAD>
>
> <?LINKREL NAVLINKS> <!-- indicate support for NAVLINKS set -->
In other words, interpret REL=xxx as REL="linkas:NAVLINKS/xxx"... ?
> <title>Section 2.3</title>
>
> <!-- the browser may give special treatment to these links:
> -->
> <link rel=top href="sec1.html">
> <link rel=next href="sec2.4.html">
> <link rel=prev href="sec2.3.html">
> <link rel=up href="sec2.html">
>
> <!-- the "cheese" link will not cause any unexpected behaviour
> because no support declaration was given for it:
> -->
> <link rel=cheese href="cheese.html">
I like this. It makes it clear that "linkas:navlinks/cheese" is what is
meant. I would like to be able to say this directly as well, though.
Also, the order of declarations would establish a precedence for lookup.
What if 'cheese' is defined in more than one name space? The only way to
disambiguate is to say 'rel=dairyproducts/cheese'. Declaring precedence would
be useful as it would make it claer that one looks for "linkas:navlinks/cheese"
first and "linkas:dairyproducts/cheese" second (if and only if it was declared).
> The support declaration PI could also include a "renaming" list
> a la HyTime; e.g., if an author uses the relations FORWARD
> and BACK and wants those to have the same meaning as the
> standardized NEXT and PREV relations, the declaration would be:
>
> <?LINKREL NAVLINKS FORWARD=NEXT BACK=PREV>
Now we are establishing equivalences, which is *really* a binding scheme.
I don't object to this but let's make it really clear that when it goes
out of the browser's back end to look it up somewhere on the net, that it
has some well-understood semantics that has already been standardized,
i.e. the URL/URI notation.
I have no objection to various defaults and declariations that make it
easier for the author to specify exactly what semantics of a link they
mean, ensure that things are interpreted uniformly within a document,
etc., but there *still* has to be a watershed name-space which lets you
specify all of this complexity in one single identifier. Otherwise each
browser will just invent their own strange/internal data structure for
doing so and it will not be standardized for distribution across networks.
In Joe's example, which is very insightful, it is clear (to me) that NAVLINKS
and DAIRYPRODUCTS are not going to be defined in a static standard, slowly
supported in specific browsers, which slowly reach the users, who wait for
browsers to support the specific links their documents use... this is not a
good match for a web environment where you are reading things written by an
author last week on a browser installed last year.
Rather, the browser will ask the network 'what are NAVLINKS?' and 'what are
DAIRYPRODUCTS?' and get the answers that it needs to interpret the various
relationships correctly. The name for *any* network-accessible resource is
supposed to be a URL/URI. Period. The tags Joe proposes are useful, and cut
the author's effort to specify the URL/URI, but in the end that is what the
browser must construct out of the various declarations.
-- Craig Hubley Business that runs on knowledge Craig Hubley & Associates needs software that runs on the net mailto:craig@hubley.com 416-778-6136 416-778-1965 FAX Seventy Eaton Avenue, Toronto, Ontario, Canada M4J 2Z5