Re: Use of Link rel+type for application discovery

On 28/01/2009, at 1:05 AM, Phil Archer wrote:

> Eran Hammer-Lahav wrote:
>> The three steps approach I described below is not really acceptable  
>> when writing software that is designed to produce consistent and  
>> predictable results. It smells more like a "guide for making  
>> friends" than a deterministic process for finding criteria-based  
>> links.
>> There are a few possible solutions:
>> 1. Decide that it is perfectly fine for an application to require a  
>> match of both the 'rel' and 'type' values.
>> 2. Use multiple 'rel' values in some required combination (in any  
>> order), for example: rel="describedby identity" will be used by  
>> something like OpenID, and will allow more than one format (in  
>> theory).
>> 3. Mint application specific 'rel' values that will imply (require)  
>> a specific content type.
>> I like #1. The market seems to be going with #3.
> I agree with you.

I think I do to, except that saying that the market is going with #3  
is perhaps stating it too strongly; there isn't enough experience yet.

>> Honestly, I find the definition of 'type' as a mere hint to take  
>> away any real value it might hold. Unlike the content type headers,  
>> links have a very specific context and exists solely within the  
>> perspective of the resource they are contained. If resource A  
>> expresses a relationship to resource B, everything about that  
>> relationship declaration is subjective, not an objective-hint.
>> Is there any documented experience for how 'type' is used in  
>> applications today?

The idea behind saying it's a hint is that a consumer should believe  
it up until the point that they actually dereference the link and  
process the response; i.e., they shouldn't blindly process what they  
get as that type. Of course, one also has to take the various,  
conflicting advice you'll get about sniffing here, but the point is  
that it's not as authoritative as the response itself (headers and  
body format), because it's "further" away.

>> Maybe Mark N can help us out here? It was he who suggested that the  
>> POWDER WG's original intention of registering rel="powder" (i.e.  
>> going for option 3 in your list) was against the spirit of the HTTP  
>> Link ID and that we should have a more generic @rel, defining a  
>> more specific content type. Can you please remind me of the  
>> motivation, Mark? If it's 'wrong' to require the presence of both  
>> @rel="foo" and type="bar" before an app has to follow a link then I  
>> agree that the case for generic @rel values is at least questionable.

I think it's unfriendly or perhaps not keeping with the spirit of the  
specs to require it with MUST language. There's nothing wrong with  
strongly encouraging it with a SHOULD. Some people will want to omit  
the type as a matter of expedience (or saving bytes), especially when  
they want just one such link.

E.g., imagine if every <a href=""> in HTML were required to have a  
type attribute.

Also, it's not good to have special case requirements for a specific  
format; it creates special cases for implementers.

I understand that it's not optimal on the wire for a client to have to  
fetch three different representations to get the right one if their  
type isn't hinted, but it's not necessary to require that they put the  
type in with a MUST; people will do it for selfish reasons anyway  
(perhaps helped along by a SHOULD).


> Phil.
>>> -----Original Message-----
>>> From: Phil Archer []
>>> Sent: Thursday, January 22, 2009 9:28 AM
>>> To: Eran Hammer-Lahav
>>> Cc: Group
>>> Subject: Re: Use of Link rel+type for application discovery
>>> Eran Hammer-Lahav wrote:
>>>> I think you know why I'm asking this.
>>> Indeed, and, as you know, I am very sympathetic!
>>>  The new relationship type 'describedby' is going to be shared by
>>> multiple descriptor formats. It is not likely that applications will
>>> support multiple formats for a single use case (that is, support  
>>> child
>>> safety ratings in both XRD and POWDER). Most applications will  
>>> choose a
>>> single descriptor format and extend its schema/syntax for their own
>>> needs.
>>>> This means, when looking to obtain such application specific
>>> descriptors, the 'type' of the document is very important. If it  
>>> cannot
>>> be trusted, it seems the implication is that applications must  
>>> perform
>>> this:
>>>> 1. Look for links with the desired 'rel'.
>>>> 2. Sort them in the order of preference based on their  
>>>> 'type' (known
>>> types first, blank type second, unknown types last).
>>>> 3. Fetch each linked document until the "right" one is found.
>>>> On the other hand, if an application specifies:
>>>> Look for a link with rel='describedby' and
>>> type='application/powder+xml' only, it makes life much easier. It  
>>> can
>>> also go further and in cases where the type is application specific
>>> (such as 'example/child-safety-3.0+xml'), require that one and  
>>> only one
>>> link is allowed/required.
>>>> While 'type' is a hint, it is authoritatively representing the
>>> viewpoint of the resource providing the link. Even of the linked
>>> resource is of a different type than indicated, shouldn't the  
>>> intention
>>> of the linking resource be allowed to use in such a way?
>>> Yes, I fully understand that and, of course, you're right - there is
>>> the
>>> potential for a lot of unnecessary (and unrealistic) processing.  
>>> Making
>>> the @rel type format-neutral (as is the case with describedby)  
>>> entails
>>> some extra mechanism for giving the format of the resource at the  
>>> end
>>> of
>>> the link. This is even more true for the multiplicity of things that
>>> can
>>> be encoded in the equally generic XML (as you know, POWDER's MIME  
>>> type
>>> is application/powder+xml) meaning that an XML parser will be able  
>>> to
>>> do
>>> 'something' with the doc, even if it doesn't understand the specific
>>> protocol.
>>> I guess this is why /de facto/ @rel types do tend to have an  
>>> associated
>>> format (stylesheet => css being the obvious example).
>>> Hmmm...
>>> The problem is the resistance already expressed by Mark Baker to  
>>> using
>>> a
>>> hint in a MUST (or perhaps even a SHOULD) (I'm assuming he's not a  
>>> lone
>>> voice). It's difficult to make a hint mandatory.
>>> Maybe it can be switched around a little.
>>> 1. Links SHOULD provide a processing hint by means of the type
>>> 2. Applications MAY ignore links that do not specify an appropriate
>>> type.
>>> That way it's clear that an application is allowed to ignore links  
>>> that
>>> are, in all likelihood, going to be irrelevant, but they are not
>>> REQUIRED to do so - it wouldn't be an error if they followed all  
>>> links.
>>> And authors get a string incentive to bother to type their links!
>>> I fear I may have split that heir a little too finely but it seems
>>> worth
>>> a shot.
>>> Phil.
>>>>> -----Original Message-----
>>>>> From: Phil Archer []
>>>>> Sent: Thursday, January 22, 2009 5:37 AM
>>>>> To: Eran Hammer-Lahav
>>>>> Cc: Group
>>>>> Subject: Re: Use of Link rel+type for application discovery
>>>>> Eran Hammer-Lahav wrote:
>>>>>> In Link headers / elements, the 'rel' attribute defines the
>>>>> relationship and the 'type' attribute provides a hint regarding  
>>>>> the
>>>>> content type of the destination resource. Is it correct to assume
>>> that
>>>>> while 'type' does not define a relationship (as in, 'image/*'  
>>>>> means
>>> 'my
>>>>> pictures'), applications may require that both the 'rel' and  
>>>>> 'type'
>>>>> attribute carry a certain value when used.
>>>>>> In other words, is it valid to say "look for a link with rel='a'
>>> and
>>>>> type='b' and only if both found, do something"?
>>>>> That seems to be a valid approach for an application to take, but
>>> one
>>>>> can also argue that the rel type might be sufficient. How many  
>>>>> HTML
>>>>> link
>>>>> headers bother to include type="text/css" alongside
>>> rel="stylesheet"?
>>>>> Without checking my guess is that browsers will all-but ignore the
>>>>> type.
>>>>> The same won't be true for other rel types.
>>>>>> I assume yes, but want to make sure this does not violate  
>>>>>> anyone's
>>>>> view on the use of 'type' in a MUST match criteria.
>>>>> Valid at the application level, but as it's a hint, then it really
>>>>> can't
>>>>> be more than a MAY at documentation level IMO.
>>>>> Phil.
>>>>> --
>>>>> Phil Archer
>>>>> w.
>>> --
>>> Phil Archer
>>> w.
> -- 
> Phil Archer

Mark Nottingham

Received on Tuesday, 27 January 2009 23:50:57 UTC