W3C home > Mailing lists > Public > public-html@w3.org > October 2009

Re: Hyperlinks and content negotiation

From: Mike Kelly <mike@mykanjo.co.uk>
Date: Thu, 22 Oct 2009 11:01:12 +0100
Message-ID: <4AE02D68.6020807@mykanjo.co.uk>
To: "Roy T. Fielding" <fielding@gbiv.com>
CC: public-html@w3.org
Roy T. Fielding wrote:
> On Oct 16, 2009, at 9:19 AM, Mike Kelly wrote:
>
>> HTML does not currently provision for hyperlinks to indicate a 
>> specific content-type preference for the Accept header of a given 
>> request.
>
> Yes, it does, at least to the extent that it is actually desirable.

I don't agree. It would be helpful to understand how and why this is the 
case - I can't find anything in 2616 to support this apparent 'threshold'

> HTML provides for that in the element or attribute semantics, along
> with the relation value in rel attributes.
>
> That is why the accept header will typically be different for
> an <a href="foo"> request versus an <img src=foo"> request.

Indeed - I don't see why this has to be to the exclusion of an 
additional mechanism for being more specific in particular hyperlinks.

>
>> This is an important feature for developers who wish to leverage HTTP 
>> content-negotiation, and require HTML hyperlinks that specify 
>> requests to URIs with a specific Accept header preference. There are 
>> use cases in which the distinction between a resource's 
>> representations are relevant to the flow of an html driven 
>> application, e.g. the difference to a browser between an atom and an 
>> html representation of a blog resource.
>>
>> <a href="/blog" type="text/html">My blog (HTML)</a>
>> <a href="/blog" type="application/atom+xml">My blog (Atom Feed)</a>
>
> That would be contrary to the design goals of content negotiation.

Is there a specific part of the http spec, or any other documents of 
relevance, I can refer to here?

>
> The purpose of conneg is to remove such explicit type indications
> from the distributed content (HTML) so that such coupling of
> standards would not be embedded in the web for eternity.

Hyperlinks with an advisory accept attribute wouldn't prevent this:

- Optional attribute /can/ be disregarded by a UA
- Accept header is not a strict contract (server free to respond with 
any content-type)

Minting new URIs for each content-type specific hyperlink is, if 
anything, less flexible in this regard.

An author who choses to indicate a specific type preference for a given 
hyperlink probably wants some form of type coupling for that particular 
next state of application flow that the link represents (i.e. a link 
described as 'My Atom feed' should be coupled to the atom content type).

> The rel
> attribute should be used to state the purpose of a generic link
> so that the user agent can adjust its acceptance criteria
> according to that purpose, not according to some specific
> media format.

Does this mean new relationships must be created/defined between 
resources for each potentially relevant negotiation discrepancy, for all 
potential UAs of a system?

Does this imply that one of the following rel values is likely to be 
wrong?     

<a rel="foo" href="/bar" type="text/html">
<a rel="foo" href="/bar" type="application/atom+xml">

> Existing formats are revised or replaced by
> alternative formats far more often than the relation semantics
> (and names) change

Possibly - is it even possible to configure browser conneg preferences 
against a particular set of relation semantics/names?

> giving the user agent the flexibility
> to support new media types without changing existing content
> is critical to enabling deployment of new types.

I agree. However, this doesn't exclude the possibility that certain 
hyperlinks are required to be specific - for the purposes of an 
application flow in which the desired state transition is distinct to a 
specific representation. This would be the case if a specific 
representation (e.g. pdf) was required, above others which the UA 
actually prefers (e.g. HTML), for the purposes of moving the information 
into another application entirely.

Cheers,
- Mike
Received on Thursday, 22 October 2009 10:01:49 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:09 UTC