RE: Inconsistencies in Discovery methods

On Feb 07, 2009 11:49 AM, "Roy T. Fielding" <fielding@gbiv.com> wrote:

> On Feb 6, 2009, at 10:48 PM, Eran Hammer-Lahav wrote:
>
> > 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.

How do you expect this contradiction to be resolved? Should the Link header simply override the meaning of 'entity-header' and be always considered 'about the request URI'?

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

I am not.

My focus is very narrow, and deals with a single relation type 'describedby' (unless this path takes me to a place that is not compatible with the ideas expressed by the POWDER spec, in which case I will mint a new relation type, like 'about').

I'm just trying to make all types of links in the same message identical. How different types of links should be used to express the same 'describedby' relation (context-type-target). From your reply it seems I can accomplish this rather easily by saying:

A 'describedby' link from a resource URI (X) to its descriptor URI can be expressed by:

* Link: headers in responses to requests where the request URI is X.
* <LINK> elements where the document is a valid representation of the resource identified by URI X.
* /site-meta templates for URI X's authority, where URI X is the transformation input.

In the example we're discussing (404), the presence of a <LINK> element in the body is simply irrelevant. This approach removes any need to explicitly discuss the HTTP status code associated with the response.

But for this to work, 2616bis will need to be very clear about which entity-body (based on the response status code) is a representation of the request URI and which is of something else. Am I asking for too much?

EHL

Received on Saturday, 7 February 2009 22:11:28 UTC