Use of Link rel+type for application discovery

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Use of Link rel+type for application discovery

Eran Hammer-Lahav

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.

EHL

Reply | Threaded
Open this post in threaded view
|

Re: Use of Link rel+type for application discovery

Mark Baker-8




On Thu, Jan 22, 2009 at 2:43 AM, Eran Hammer-Lahav <[hidden email]> 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"?

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

Mark.


Reply | Threaded
Open this post in threaded view
|

Re: Use of Link rel+type for application discovery

Phil Archer-3
In reply to this post by Eran Hammer-Lahav



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/

Reply | Threaded
Open this post in threaded view
|

RE: Use of Link rel+type for application discovery

Eran Hammer-Lahav

I think you know why I'm asking this. 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?

EHK


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

Reply | Threaded
Open this post in threaded view
|

Re: Use of Link rel+type for application discovery

Phil Archer-3



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:[hidden email]]
>> Sent: Thursday, January 22, 2009 5:37 AM
>> To: Eran Hammer-Lahav
>> Cc: [hidden email] 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/

Reply | Threaded
Open this post in threaded view
|

Re: Use of Link rel+type for application discovery

Andreas Sewe-2
In reply to this post by Eran Hammer-Lahav

Eran Hammer-Lahav wrote:
> 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.

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

Reply | Threaded
Open this post in threaded view
|

RE: Use of Link rel+type for application discovery

Eran Hammer-Lahav
> 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'.

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
Reply | Threaded
Open this post in threaded view
|

RE: Use of Link rel+type for application discovery

Eran Hammer-Lahav
In reply to this post by Phil Archer-3

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



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

Reply | Threaded
Open this post in threaded view
|

Re: Use of Link rel+type for application discovery

Phil Archer-3



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:[hidden email]]
>> Sent: Thursday, January 22, 2009 9:28 AM
>> To: Eran Hammer-Lahav
>> Cc: [hidden email] 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:[hidden email]]
>>>> Sent: Thursday, January 22, 2009 5:37 AM
>>>> To: Eran Hammer-Lahav
>>>> Cc: [hidden email] 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/

Reply | Threaded
Open this post in threaded view
|

Re: Use of Link rel+type for application discovery

Mark Nottingham-4


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

Cheers,


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

--
Mark Nottingham       [hidden email]



Reply | Threaded
Open this post in threaded view
|

Re: Use of Link rel+type for application discovery

Eran Hammer-Lahav



On 1/27/09 3:50 PM, "Mark Nottingham" <[hidden email]> wrote:

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

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.

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

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.

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

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.

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

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

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

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

EHL