Re: Use of Link rel+type for application discovery

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.

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

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.

Phil.


> 
> 
>> -----Original Message-----
>> From: Phil Archer [mailto:phil@philarcher.org]
>> Sent: Thursday, January 22, 2009 9:28 AM
>> To: Eran Hammer-Lahav
>> Cc: ietf-http-wg@w3.org 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 [mailto:phil@philarcher.org]
>>>> Sent: Thursday, January 22, 2009 5:37 AM
>>>> To: Eran Hammer-Lahav
>>>> Cc: ietf-http-wg@w3.org 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. http://philarcher.org/
>>>
>> --
>> Phil Archer
>> w. http://philarcher.org/
> 

-- 
Phil Archer
http://philarcher.org/

Received on Tuesday, 27 January 2009 14:06:33 UTC