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

Either they have a clear meaning or they don't. If the interaction between rel and rev is application specific, what is the value of having rev in the spec? It doesn't help with interop.

For example, if the response to GET /resource/2 is:
Link: <http://example.com/resource/1>; rev="next"

It can either be the *same* as a GET /resource/1 returns:
Link: <http://example.com/resource/2> rel="next"

OR

Can be equally expressed like this (in response to GET /resource/2):
Link: <http://example.com/resource/1>; rel="rev/next"
Where a 'rev/' prefix means the same rel but inbound.

To leave the choice between these interpretations two up to each application seems to void the benefit of having both rel and rev. I think the second interpretation is the right one, which calls for dropping 'rev'.

EHL


On 12/3/08 2:39 AM, "Mark Nottingham" <mnot@mnot.net> wrote:

I think the key is to define the semantics of rel vs. rev well enough
that a relation doesn't necessarily have to say something about them,
but that it still can without conflicting.

Yes, that's a fine line to walk.


On 03/12/2008, at 8:53 PM, Phil Archer wrote:

> I'd just like to jump in on one point:
>
> Eran Hammer-Lahav wrote:
> [..]
>>>>>  Each link-value MUST have at least one "rel" or "rev" parameter
>>>>> whose
>>>>>  value indicates the relation type.  If the "rel" parameter is
>>> used,
>>>>>  it indicates that the link's direction for that relation type is
>>>>>  outbound; if the "rev" parameter is used, the given relation
>>> type's
>>>>>  direction is inbound.
>>>> Is 'rev' considered as authoritative as 'rel' (as in, 'type' is
>>>> non-
>>>> authoritative, just a hint)? Forward looking links using 'rel' are
>>>> clearly authoritative as they indicate the view-point of the
>>>> resource, which has the authority to declare its own perceive links
>>>> to other resources. However, 'rev' can go both ways. It seems to be
>>>> semantically equivalent to an identical 'rel' coming from the
>>>> linked
>>>> resource. For example:
>>>>
>>>> Resource A: Link: <http://example.com/b>; rel="friend"
>>>> Resource B: Link: <http://example.com/a>; rev="friend"
>>>>
>>>> If the two are semantically identical, 'rev' must be non-
>>>> authoritative as it serves as a hint as to what another resource
>>>> view the relationship as: "A declares B to be <<its friend>>, B
>>>> hints that A <<declares B its friend>>". However, if 'rev' is meant
>>>> to be authoritative, the two links above cannot be semantically the
>>>> same, as they read: "A declares B to be <<its friend>>, B declares
>>>> that A <<consider it a friend>>". The question is, is 'rev' simply
>>>> an implied 'rel' from the other direction (and so, non-
>>>> authoritative), or 'rev' is a reverse "opinion" of 'rel' which is
>>>> completely relative to the resource regardless of any actual 'rel'
>>>> from the other direction (and so, authoritative).
>>> This draft isn't attempting to establish a framework for semantics
>>> or
>>> trust, and I'm tempted to take out anything that might imply this...
>> I think at a minimum it needs to clearly define the relationship
>> between 'rel' and 'rev'. This is why I liked it better when 'rev'
>> was dropped. If you only have 'rel', you can express 'rev' with
>> another 'rel' value, and that will solve my issue. If you keep
>> both, I can't see how you can avoid explaining their relationship
>> to one another as listed in the example above.
>
> I just wrote out an argument for why I felt it was important to keep
> rev... and realised that my own arguments convinced me that it
> probably isn't needed for HTTP Link after all. The arguments over
> the relative authority and semantics of rel and rev links is pretty
> compelling.
>
> 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.
>
> Phil.
>
> --
>
> Phil Archer
> w. http://philarcher.org/


--
Mark Nottingham     http://www.mnot.net/