Re: Inconsistencies in Discovery methods

On Feb 6, 2009, at 10:48 PM, Eran Hammer-Lahav wrote:

> This solves my problem with regard to the Link header.
>
> On Feb 06, 2009 4:41 PM, "Roy T. Fielding" <fielding@gbiv.com> wrote:
>
>> The Link header field defines what it is about: [RFC2068]
>>
>>     The Link entity-header field provides a means for describing a
>>     relationship between two resources, generally between the  
>> requested
>>     resource and some other resource.
>
> Isn't this a bit of a contradiction? The same spec defines entity- 
> header as:
>
>     Entity-header fields define optional metainformation about the
>     entity-body or, if no body is present, about the resource  
> identified
>     by the request.
>
> (which is identical to the language in the most recent draft  
> without the word 'optional').
>
> A 404 response can have an entity-body, which you defined as  
> "representation of a resource on the server that describes that  
> error". So a Link header on a 404 with no body is consistent  
> between the Link header definition and the entity-header  
> definition. But if a body is present, they contradict each other.

Yes, we had several "category errors" in 2068, largely because we
chose the wrong names for the categories.  Some of them were fixed
in 2616, and they'll most likely be different in 2616bis.
Don't worry about that.

However, I think your attempt to make all types of links in the same
message be mirrors is unnecessary. In many cases, the relation name
will have implications beyond the resource being targeted, and in
other cases the links will simply be wrong if expressed as resource
metadata (e.g., a link rel="author" for which the relationship is
only true for one of the representations of this resource).

We could resolve that ambiguity by differentiating where the link
is indicated (link: vs content-link, <link> vs <a>) or by
differentiating the relation names (e.g., owner vs author).
Neither option has been used consistently in the past and I doubt
that it will ever be consistent in the future.

....Roy

Received on Wednesday, 11 February 2009 01:12:09 UTC