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 

I guess this is why /de facto/ @rel types do tend to have an associated 
format (stylesheet => css being the obvious example).


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.


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

Received on Thursday, 22 January 2009 17:28:42 UTC