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

That's just syntactic sugar...

On 04/12/2008, at 10:34 AM, Eran Hammer-Lahav wrote:

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


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

Received on Thursday, 4 December 2008 02:46:24 UTC