The checkered history of @rel

(For some reason, I left this as a draft when I wrote it last May, inspired by Atom autodiscovery. Sure, it’s unclear, and argues for things that I wish weren’t true, but if I let that stop me I’d write even less. Since WordPress will keep nagging me until I either publish it or delete it, publish it is.)

While I’d read them all before, I hadn’t ever looked at the sections of the various HTML specs and recs dealing with the rel attribute of a and link elements all in one sitting before. It’s interesting, if not very instructive.

HTML 1: Like DOM 0, HTML 1 didn’t really exist beyond the rough intersection of how people were doing things. Still, draft-ietf-iiir-html-01.txt is a useful glimpse of HTML as it started toward formal standardization. Both A and LINK had optional REL attributes, whose values were described in a non-normative section as something the authors hoped would be registered by IANA, with unregistered values being preceeded by X-. The listed values included such things that make nofollow seem a model of relationship semantics as USEINDEX, EMBED, and PRESENT (meaning a user agent shouldn’t present the document without also presenting that linked document).

HTML 2.0: The first HTML spec to make it through standardization, it backs far, far away from the previous fixed list with precise meanings, saying only that The semantics of link relationships are not specified in this document.

HTML 3.2: Notable as both the first W3C HTML spec (2.0 was an IETF RFC, rather than a W3C Rec), and as the most heinous use of a paint-splatter background image in a specification that people still read today, HTML 3.2 showed only a little advance from 2.0 in rel values, saying HTML link relationships are as yet unstandardized, although some conventions have been established.

HTML 4.01: Depending on how you handicap the WHAT-WG’s chances, the HTML. For the most part unchanged since 1997, it still defines element meaning in XHTML. The section on link types is fitting for something that would be the only source of authority for anyone arguing about such an abstract thing for so many years. Attribute values are presented with their conventional meaning, so that anyone who wants another interpretation can say that it’s only conventional, not prescriptive, and can say that saying user agents may interpret these link types in a variety of ways means that they have only the shared meaning of any two people who happen to agree (or, given the spec’s focus on search engines, between a search engine and the authors who write markup tailored to it).

Unlisted attribute values are allowed, but should be defined in a profile attribute, one of the clearest indications that the HTML 4 authors didn’t feel that they were done yet. The value of the profile attribute is a space separated list of URIs, where only the first one counts. It may be recognized, or dereferenced, getting… something that then… something something. The first URI in the list acts as a namespace, not only for rel values but also for the value of the scheme attribute on meta elements, so that the true meaning of <meta name="ambiguous" value="very"> is determined by both the scheme="not" attribute, and the profile="http://inmyworld.com/ http://notinyours.com" attribute. Had the world turned differently, I bet HTML 4.5 would have kicked some semantic relationship butt.

Just to give strict constructionist semanticians as much pain as possible, along with a few non-prescriptive examples of rel="alternate" with hreflang="..." for the current document in another language, the spec has exactly one prescriptive use of link with rel="alternate", where alternate stylesheets combine two separate rel values to mean that alternate applies not to the linking document, but to the other value. Makes for quite a bit to hand-wave away, if you want to say that rel="alternate" means exactly what you want it to mean, and nothing more.

8 Comments

Comment by Michael Fagan #
2005-11-19 16:23:54

Thanks for writing this. I started writing a similar long bit about rel values a month or two ago, and it’s sitting as a draft in my work email account.

Don’t forget about @rev, by the way, which is part of HTML (not sure when it was introduced), but is not part of Atom’s description of the link element.

Atom’s @rel, if I understand correctly, may have only one value (not space-separted values), unlike HTML. And Atom allows values from a fixed list (IANA) or a URI.

For OpenSearch we’re looking at getting ’search’ added as a @rel value to that IANA list.

Separately, but related to OpenSearch, I’m working on a new proposal which involves @rel, as a space-separated list of values being one of a fixed list, or namespaced, such as rel=”ns:foo”, although perhaps I should change this to rel=”http://namespace-uri/#foo”, to better correspond with Atom?

Comment by Phil Ringnalda #
2005-11-19 17:12:02

Ah, maybe it was a draft because it lacked context: I wrote it for Atom autodiscovery, not atom:link, in the context of some discussion of whether you should link to your feed(s) with rel="alternate" even when you are linking to your main feed from an individual entry, or your comment feed from your main page.

And the fact that it’s confusing because <atom:link atom:rel=…> is somewhat like but not exactly <xhtml:link xhtml:rel=…> should probably go into my still-draft ”Reuse is not a magic wand.”

 
 
Comment by Michael Fagan #
2005-11-19 18:45:18

I dislike pointing to all feeds with rel=”alternate” regardless of it actually being an alternate…

The same issue (re your last paragraph) is there with OpenSearch.. trying to get rel=”search” via the IANA list with Atom and via a profile in the head with HTML. rather messy.

I’ve also been pondering something like rel=”cache” for search engines’ caches, but this needs to be thought through more thoroughly

 
Comment by Eric Meyer #
2005-11-27 22:29:18

I know you know this, Phil, but I thought I’d record it here for anyone who might come along and not know it: @rel (along with @profile) has seen a recent renaissance with some microformats, first and most notably XFN.

Comment by Aristotle Pagaltzis #
2005-11-28 10:20:08

And of course, while the idea looks really simple and elegant and neat, its semantics are all wrong. <a rel="friend" href="http://example.com/"> asserts that “the resource you are currently viewing is a friend for the http://example.com/ resource,” when what you actually want to say is “the owner (or author, or some otherwise suchly related entity) of the resource yu are viewing is a friend of the owner of the http://example.com/ resource.” Which might be pedantry, were it not for the problem that XFN defines absolutely no way in which a metadata harvester can discover who the owner (or author, or …) of each respective resource actually is.

So in its current state, XFN is only useful as human-targetted annotation. As machine readable data, it is a failure.

Comment by Eric Meyer #
2005-11-28 10:23:38

”As machine readable data, it is a failure.”

Which is really funny, because I know of machines (okay: software) that are reading that data and doing interesting things with it.

Comment by Aristotle Pagaltzis #
2005-11-28 11:05:07

I don’t doubt that you can do interesting things with information about a mesh of webpages. An entire business model called Google is based on that. What I said it’s not the same as doing interesting things with information about a mesh of people.

Or do the tools you speak of correlate the XFN mesh with information about the people which isn’t linked directly from the pages that stand in for them?

 
 
 
Comment by Phil Ringnalda #
2005-11-30 22:29:54

I suspect that was another nagging grain of sand refusing to turn into a pearl, that kept me from thinking I was done writing.

XML namespaces, for all their troublesome aspects, neatly solve the problem of ”everybody wants to call their own particular sort of identifier ’id’” by letting anyone who can mint a URI say that this particular instance of ’id’ is their sort of identifier.

HTML rel and friends as interpreted by XMDP solve the problem by requiring anyone who wants to use more than one set of definitions to carefully order them so that conflicts are resolved in the way they want, and to avoid using those things that conflicts prevent them from using.

I understand the situation, that it’s nobody’s fault other than the way the work of the HTML WG fell out, but that’s just awful design. Terrible. Horrifying.

 
 

Sorry, the comment form is closed at this time.