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

Hello Mark,

> -----Original Message-----
> From: Mark Nottingham [mailto:mnot@mnot.net]
> Sent: 04 December 2008 04:04
> To: Williams, Stuart (HP Labs, Bristol)
> Cc: ietf-http-wg@w3.org; Eran Hammer-Lahav
> Subject: 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.

I guess I find that surprising. Can you explain the intended semantics including a link header in a PUT/POST request. eg. is it saying please establish a link between the requested resource (or a resource created in response to a POST) and the link target? ie. is it intended as a way to establish link relations that are subsequently reported in GET/HEAD responses?

If that's the case I would still view that as a relation established between requested and targetted resource (though in the POST case I can see a case for the relation being established with the resource referenced by any Location: header rather than the requested 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.

This is the tricky use of the word 'document'. Document is one of those words that can pun between a resource like thing or a representation like thing.

Links are reported in document representations - because the document resource which they are a representation of is so linked... but the link is between resources, even 'in-document' - that just happens to be manifest in the conveyed representations.

> 3) a link from a representation to another resource implies an inter-
> resource link, since the representation is (usually) tied to an
> explicit resource.

Eggs and chickens... on the whole I think that we agree. However, can you explain to me how I make reference to a representation - the one that I got this morning when I accessed the W3C web site? How do I do that conveniently with a URI?

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

There is a type/token thing going on here. We are not clear whether by representation we are speaking of (roughly) a particular message that crossed a particular interface at a particular time; or whether we are talking about a class of messages that all convey the same literal sequence of bits.

Regardless, even with the (latter) coarser grained notion of representation - the representation is a view of the resources state - it is not the resource; it may not expose all the links that there resource may have; and it may change over time. Most crucially AFAIK there is no systemic way of making reference to one using a URI.

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

I am not suggesting that it should. I'm suggesting that the Link header be specified in a way that is consistent with web architecture.

http://www.w3.org/TR/webarch
"Link
A relationship between two resources when one resource (representation) refers to the other resource by means of a URI. "

Though I would concede that we are perilously close to dancing on the head of a pin.

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

--
Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England

Received on Thursday, 4 December 2008 11:55:13 UTC