> This is the case now, but nobody has implemented REL/REV except SCO.
Also, Lynx interprets <LINK REV=MADE HREF="mailto:..."> as the
"document creator" in its "send e-mail to document creator" command.
> > [...] 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.
Not necessarily; for example, a support declaration like:
<?linkrel popup-windows footnote=popup>
could be used (given a suitable published definition for the
"popup-windows" link relation set) to mean that the linkend
of all <A REL=footnote> elements should be rendered in a pop-up
window.
> 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.
By "published" I mean anything from "has been published as an RFC"
or "has been submitted as an Internet-Draft" to "has been mentioned
briefly on html-wg" or "we talk about it somewhere in our release
notes".
"Published" could also mean "Hot-Java, Safe-tcl, Scheme, and DSSSL
source code to interpret these link relations is available at
this URL (use the usual HTTP format negotiation mechanisms to
retrieve whatever code you can execute, Mr. User Agent)", in which case the
URL in question would indeed be a valuable thing to include in the
document, but that's just wishful thinking right now IMO.
(Especialy since format negotiation is not yet widely deployed,
let alone donwloadable executable browser code. Note that author-
defined link relations with no special treatment by the browser can
also be a valuable thing to encode in the REL= attribute.)
> > <HTML>
> > <HEAD>
> >
> > <?LINKREL NAVLINKS> <!-- indicate support for NAVLINKS set -->
>
> In other words, interpret REL=xxx as REL="linkas:NAVLINKS/xxx"... ?
Not exactly; it would just mean to interpret REL=NEXT,
REL=PREVIOUS, REL=TOC, and REL=INDEX with the semantics
specified in the document which describes the NAVLINKS link
relation set. (A programmer-type human being would still have
to read that document to implement the semantics.) REL=xxx for
any other "xxx" would still be interpreted as an author-defined
relation with no special treatment (unless of course other
<?LINKREL ...> PIs were present).
> Also, the order of declarations would establish a precedence for lookup.
> What if 'cheese' is defined in more than one name space?
I think the HyTime-style renaming specification can handle this
(if it in fact ever becomes a problem).
> 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...
Actually, that's exactly the scenario I had in mind.
> 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.
That would be nice, to be sure, but I had a more modest goal: I
just want to make sure that authors can use whatever link relation names
they feel are appropriate today, take advantage of the information
encoded in their documents tomorrow when and if browsers are capable
of using it, and not worry about tomorrow's browsers doing something
unexpected with that information because of nameclashes.
(Again, this is also important for predefined CLASS= attribute
values.)
--Joe English
joe@trystero.art.com