W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2008

Re: Feedback for draft-nottingham-http-link-header-03

From: Mark Nottingham <mnot@mnot.net>
Date: Sat, 6 Dec 2008 20:50:40 +1100
Cc: HTTP Working Group <ietf-http-wg@w3.org>, Ian Hickson <ian@hixie.ch>, Drummond Reed <drummond.reed@cordance.net>, Phil Archer <phil@philarcher.org>
Message-Id: <A2EBCB67-7617-41E4-9B50-80A7C1269568@mnot.net>
To: Roy T. Fielding <fielding@gbiv.com>

My own use case for this type of link is that I want to define an  
"invalidates" relation, whereby if it's a rel, it says "when this  
resource's state changes, it invalidates cached responses from that  
one", and whereby if it's a rev, it means "when that resource's state  
changes, it invalidates cached responses from this one."

Early experience with users mirrors what Ian and Roy are talking  
about; namely, that the distinction (a single letter) often confuses  
or is overlooked. I'm happy to define "invalidates" and "invalidated- 
by". I.e., while it's replacing an inbound link, it stands as an  
outbound link on its own (I'm not thrilled with the 'rev-*' solution).

Stepping back, though, I think the key question is whether the link  
framework (which is what the draft has become) should support inbound  
links. Right now, it's in an awkward state where it allows some  
applications (Atom being the most notable one, and it looks like HTML5  
is going to fall into this boat too) to only allow one type of link.

If we disallow inbound links (i.e., take them out of the prose, but as  
Roy says, still allow them in the syntax, for compatibility), we'll  
avoid this confusion and also gain some consistency between the  
serialisations. The only apparent loss is that of inbound links, and  
if I had to characterise the discussion I've seen so far, it's that  
their proponents think that they'd be *nice* to have, but I don't see  
anybody lying down in the road to save inbound links; indeed, when we  
re-added them, it was based on one or two people saying as much, IIRC.

Have I missed something? Otherwise it looks like we're moving towards  
taking 'rev' out (but still allowing it as a link-extension  
syntactically). Note that we're still going to update to say that rel  
links are resource->resource.

One note; earlier, Phil said:

> And yet, and yet... I would still be concerned to see it go because  
> it is *really* useful in RDFa. HTML 5 has dropped rev for the link  
> element and if the tide is against keeping rev in HTTP Link then the  
> impression being given might be that rev is deprecated everywhere.  
> Even though that is not what is being said or implied here, it could  
> lead to future confusion.


Since the re-casting of the draft to talk about a framework for typed  
linked generically, I think this is now indeed what is being said,  
with the caveat that others (including the Semantic Web world) can  
build on top of it if they wish. Given the uncertainty / confusion  
around this kind of link for the layman, I personally think that's  
appropriate.

Cheers,


On 06/12/2008, at 7:14 PM, Roy T. Fielding wrote:

>
> 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
>


--
Mark Nottingham     http://www.mnot.net/
Received on Saturday, 6 December 2008 09:51:23 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:58 GMT