Re: Use of Link rel+type for application discovery

On 1/27/09 3:50 PM, "Mark Nottingham" <mnot@yahoo-inc.com> 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

Received on Thursday, 29 January 2009 23:53:00 UTC