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

On 05/12/2008, at 7:13 AM, Williams, Stuart (HP Labs, Bristol) wrote:
>>
>> Resource
>> discovery (XRDS, POWDER, OpenID, etc.) depends on links
>> having a resource and not representation context. But again,
>> there are easy implementation-based solutions if the spec
>> goes the representation way.
>>
>> I prefer to define links as between resources regardless of
>> their representation mostly for the following reasons:
>>
>> 1. I think links should be symmetric and 'representation -->
>> resource' isn't symmetric. 'resource --> resource' is nice and clean.
>> 2. If a 'rel' link is defined as 'representation -->
>> resource' that forces 'rev' to be 'resource -->
>> representation'. It means that 'B --(rev)--> A' has nothing
>> to do with 'A --(rel)--> B' because each is between different
>> objects (resource / representation).
>> 3. The other way to accomplish symmetry is 'representation
>> --> representation' which has been rejected here before. That
>> would shift the meaning of 'type' from a hint to an actual
>> part of the relationship context (needed to define the
>> representation of the linked resource in context for the link).
>>
>> Yes... I think those three points also make the case quite nicely.
>
>> There are clear implications for defining link as
>> 'representation --> resource' vs. 'resource --> resource'.
>> One of them is the impact of the definition of the 'rel/rev'
>> relationship. All I am asking for is clarity.
>
> I'd be interested to know whether we have persuaded Mark (yet)...  
> Mark?

I think you have.

Looking back at the source text from 2068, it *does* talk about  
resource-to-resource links, and this is supported by the "anchor"  
attribute that Julian reminded us about.

The one quibble I have is with this notion of a "canonical" set of  
links; there can always be more links between resources than are  
serialised into the headers (unless it's specifically required by an  
application; see below). This is important, because it allows (for  
example) an HTML representation to carry HTML-centric links, while  
allowing an XML representation of the same resource to carry XML- 
centric links, if that's what's desirable, without conflicting.

Eran, if you want to say that all responses for a particular resource  
must contain a particular link, go ahead and specify just that; even  
if we clarify Link to say that links *are* resource->resource, there's  
no guarantee or implication that all responses will have a Link  
header...

Cheers,

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

Received on Friday, 5 December 2008 00:58:44 UTC