I agree with the principle, and disagree with the name scheme. I think
the appropriate name space for link types/behaviors is URLs/URIs. Thus the
idea of "linkas:..." names.
The "X-" method works ONLY for names that are supposed to be interpreted as
browser behaviors. This is NOT the only useful kind of typed link, and we
ultimately want the ability to retrieve a definition from someplace. That
means we are back to URLs/URIs (I am really trying hard to avoid inventing
new ways to specify a name space). The "mailto:..." is the precedent, it's
a browser behavior that is specified as a URL, has an argument embedded
in it (the email address), and can appear in place of an HREF in an anchor.
Rather than letting proliferating link types fill up the URL/URI name space,
and confusing browsers that don't understand "toc:...", I think we ought to
support REL=xxx for now, taking the HREF as its argument, and ultimately be
moving to some more generic means of specifying a link as a fn with arguments.
URLs/URIs are "generic" in that they are not restricted to the HTML language.
This matters because, if linking behavior is not supportable across the
various different languages/formats on the Web, we'll end up splintered!
A bad thing... A baroque mechanism with several different name spaces,
several different means of specifying arguments, etc., has no hope of
being adopted in PDF, SGML, VRML, RTF, and god knows what horrors to come.
We need to be concerned about what *all* Web browser implementors (including
those working on non-HTML browsers) will consider to be a single clean mechanism.
They understand URLs/URIs, they understand "mailto:...", they will understand
and implement something that simply fills in the gaps. A list of names that
only fit in REL and an "X-xxx" breakout mechanism does not solve this problem.
It simply makes the HTML-style anchor more baroque and hard to implement
> I certainly support having a list of REL and REV values, and I also support
> people experimenting with new ones, but I must admit that I question the
> value of sticking a "X-" on the beginning of an experimental value. I take
> it as a given that software will not fail on encountering a value that it
> doesn't support, and if you stick on "X-" on the beginning of experimental
> things, it just means you need to change your software once it does get
> standardized (Because the act of standardization changes existing practice).
Yes. However, software will already know how to deal with known/unknown
found/unfound URLs, and will have reasonable default behavior built in when
a bad one is found in a specific context. In other words, default unknown
link types, e.g. "linkas:flying_leap" to a "linkas:goto" (the standard) with
a link type name of "flying leap". Or look them up if a server is named in
the linkas (not proposing this yet, just leaving the door deliberately open).
Draft on this should be ready next week, now that Murray's back.
-- 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