Subject: Use of Link rel+type for application discovery

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 22 Jan 2009 00:43:13 -0700

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

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.

EHL

---

From: Mark Baker <[email-masked]>
Date: Thu, 22 Jan 2009 12:43:50 +0000

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

As you point out, "type" is only a hint, so I wouldn't recommend that approach.

Mark.

---

From: Phil Archer <[email-masked]>
Date: Thu, 22 Jan 2009 13:36:57 +0000

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

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 22 Jan 2009 09:39:55 -0700

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

EHK

> -----Original Message-----
> From: Phil Archer [mailto:[email-masked]]
> Sent: Thursday, January 22, 2009 5:37 AM
> To: Eran Hammer-Lahav
> Cc: [email-masked] 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"?
>
> > 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.
>

---

From: Phil Archer <[email-masked]>
Date: Thu, 22 Jan 2009 17:27:57 +0000

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

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.

---

From: Andreas Sewe <[email-masked]>
Date: Fri, 23 Jan 2009 09:27:47 +0100

> 3. Fetch each linked document until the "right" one is found.

The last one should ideally be 'Fetch each linked document *with the
Accept header set to the known types* until the "right" one is found.'

Just my 2 Zorkmids.

Andreas Sewe

P.S.: Please do us a favor and use a hyphen in your proposed @rel value:
'describedby' is some much less readable than 'described-by'.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 23 Jan 2009 14:45:30 -0700

> 'describedby' is some much less readable than 'described-by'.

I have no strong opinion about including a hyphen in the rel name, but it is not my proposal, but that of Phil Archer / POWDER community.

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 23 Jan 2009 15:59:38 -0700

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.

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?

EHL

> Sent: Thursday, January 22, 2009 9:28 AM
> To: Eran Hammer-Lahav
> > 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:
> >
> > 2. Sort them in the order of preference based on their 'type' (known
> types first, blank type second, unknown types last).
> > 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?
>

---

From: Phil Archer <[email-masked]>
Date: Tue, 27 Jan 2009 14:05:47 +0000

> I like #1. The market seems to be going with #3.

I agree with you.

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

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

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 28 Jan 2009 10:50:00 +1100

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

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

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.

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

Cheers,

>>> some extra mechanism for giving the format of the resource at the  
>>> end
>>> of
>>> is application/powder+xml) meaning that an XML parser will be able  
>>> to
>>> do
>>> The problem is the resistance already expressed by Mark Baker to  
>>> using
>>> a
>>>>> while 'type' does not define a relationship (as in, 'image/*'  
>>>>> means
>>> 'my
>>>>> can also argue that the rel type might be sufficient. How many  
>>>>> HTML
>>>>> link

--
Mark Nottingham       [email-masked]

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 29 Jan 2009 16:52:16 -0700

> is perhaps stating it too strongly; there isn't enough experience yet.

Which is why I said 'seems'... Yes, there is practically no experience yet
to help developers in making decisions as to how Links should be used. Which
is why it is attractive to mint custom rel types which have a singular
definition and a trivial way of specifying a resolution workflow.

> body format), because it's "further" away.

This definition of a hint is very helpful. I read it to mean that for the
purpose of selecting a relevant link, it is more than just a hint, but once
a representation of the linked resource has been obtained, its own HTTP
header/metadata is authoritative to how it should be interpreted.

> they want just one such link.

Which is fine for many rel types, but not when the rel type by itself is
enough to make any useful determination as to the applicability of a found
link to the application at hand.

Considering 'describedby', the type is as important to the selection process
as the rel.

> format; it creates special cases for implementers.

But the 'rel' type already dictates a special case.

> (perhaps helped along by a SHOULD).

Which contradicts your initial agreement to #1 above... :-)

EHL