- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Sat, 6 Dec 2008 00:14:15 -0800
- To: HTTP Working Group <ietf-http-wg@w3.org>
- Cc: Ian Hickson <ian@hixie.ch>, Drummond Reed <drummond.reed@cordance.net>
On Dec 5, 2008, at 9:53 PM, Drummond Reed wrote: > Some recent feedback on Link Header highlights a serious issue with > that > workaround. Even if HTML5 drops "rev", it doesn't change the semantics > established in HTML4, RDFa, and other uses that "rel" and "rev" assert > outbound and inbound links, respectively. Umm, no, they don't assert inbound links. The only deployed value for rev (rev="Made") defines a link from this representation of a resource to its maker. The only thing directional about it is the relation name itself, which implies an out relation, but it is the relation that is reversed by rev=name, not the link. In your words, rev asserts an inbound relationship as an outbound link. The semantics of most relation names do imply that an inverse relationship must also be true. However, that applies to both rel and rev. For example, "X rel=parent Y" implies that the relation "X is a child of Y" is true even if there is no corresponding link (a link on representation of Y that explicitly says "Y rel=child X"). IIRC, the rationale for having both rel and rev was because restricting the names to a unidirectional set of relations would reduce their number (as opposed to minting the relation names in pairs). In practice, however, that didn't work. People don't communicate that way -- they mint new relation names all the time. And they don't do it in generalities. In fact, rev=made and rel=author do not mean the same thing: we are far better off if we encourage people to use more specific, easily understood relations like "author", "artist", "composer", "sculptor", and so on. Programs can infer the inverse and superset relations. It is far easier to change the software to infer more generic relations with inverse tables and implications than it is to change how people choose to communicate. I would prefer that rev be deprecated (parsed without error but discouraged in documentation and validation). ....Roy
Received on Saturday, 6 December 2008 08:15:00 UTC