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

Hey Stuart,

I'm inclined to say that they're tied to the representation for a few  
reasons;

1) a Link header can potentially be included in a request as well;  
e.g., on a POST or PUT request body. In such a case, there is at best  
an ephemeral/virtual resource.
2) links' grounding in entities is already pretty explicit in the  
history of the link header as well as implied by in-document links.
3) a link from a representation to another resource implies an inter- 
resource link, since the representation is (usually) tied to an  
explicit resource.

Think about it from how in-document links work; if a response contains  
a <link>, the link is resolved using the document's URI -- which does  
identify the resource -- as the base URI for resolving the target, as  
well as the context of the link. The representation *isn't* ephemeral,  
it's a representation of an identified resource.

So I don't think we're disagreeing at heart; it's just that the  
relationship between the representation and the resource is already  
defined by the Web architecture, and shouldn't be re-specified by  
links...



On 04/12/2008, at 2:20 AM, Williams, Stuart (HP Labs, Bristol) wrote:
>
> Oh dear... I think we need to be clear about the whether the  
> relations being conveyed in Link: headers are intended to hold  
> between resources or between the conveyed representation and  
> whatever the target URI refers to.
>
> Personnally, my hope is that the relations are regarded as holding  
> between the resources that are referenced by URIs (as opposed to one  
> party to the relation being a more ephemeral representation or  
> message being conveyed).
>
> Of course the question is what resource supplies the context,  
> particularly in the case of a response that carries a "Content- 
> Location:" header that carries a different URI from that in the  
> request.
>
> It seems to me that candidate choices for the context resource are:
>
> a) the resource referenced in the request line of the corresponding  
> HTTP request.
> b) the resource referenced in a Content-Location: header returned in  
> the same response.
>
> are there any other candidates?
>
> Does one take a) as the default and allow b) if present to override  
> a), or simply stick with the original request URI.
>
> Simplicity suggests just a) and that if you want to find out about  
> links associated with the resource reference by a "Content- 
> Location:" then you go ask there.
>
> Regards
>
> Stuart
> --
> Hewlett-Packard Limited registered Office: Cain Road, Bracknell,  
> Berks RG12 1HN
> Registered No: 690597 England
>
>
>


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

Received on Thursday, 4 December 2008 04:05:03 UTC