RE: Use of Link rel+type for application discovery

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

Received on Friday, 23 January 2009 23:00:26 UTC