Hyperlinks and content negotiation

Hello list,

Thanks in advance for your time and attention on this. With that, I'll 
get straight to the point:

HTML does not currently provision for hyperlinks to indicate a specific 
content-type preference for the Accept header of a given request.

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>

Without a formal mechanism in HTML which can specify to UAs the 
contextual content-type preference for a given hyperlink, HTML is not a 
viable hypermedia format for systems which must rigorously leverage HTTP 
conneg - this /could/ be achieved with representation specific URIs 
(i.e. format 'suffixes', URI parameters etc.) but there are situations 
in which conneg is a superior solution, particularly in terms of the 
system as a whole, taking into account intermediaries such as caches.

It seems a shame that this, perfectly valid, use of HTTP is not allowed 
to system developers that must implement HTML driven applications. 
Furthermore - it does not seem that potential enabling solutions would 
cause incompatibility with existing HTML applications currently not 
concerned with conneg.

I would therefore, like to suggest that an enabling solution be formally 
provisioned within the HTML5 spec which will encourage UA adoption and, 
in turn, create an environment in which systems developers have a choice 
over whether or not to use HTTP content negotiation.

It may be worth noting that the XInclude spec defines an accept attribute for links ( http://www.w3.org/TR/xinclude/#include_element ), for this purpose.


I can see two potential solutions to this problem:

1. Definition of @type altered to specify clients SHOULD interpret @type 
attribute to specify appropriate Accept header for the request. I have 
raised a bug against the spec for this already which contains further 
details of the rationale for this suggestion - however it's status was 
set to resolved before any significant discussion took place.
( http://www.w3.org/Bugs/Public/show_bug.cgi?id=7697 )

2. A new optional attribute introduced for hyperlink elements; @accept 
with a spec definition that UAs SHOULD over-ride Accept header for 
requests indicated by hyperlinks which include the attribute. If @accept 
specifies media type outside of the generic set of content-types 
acceptable to a given UA then the UA MAY revert to its generic header 
and make the request OR prevent the request from proceeding altogether.

I would be interested to hear others' thoughts on this, what the next 
stages are if this is to be included in the spec, etc.

Please could I ask that I am cc'd in any responses since I am not 
subscribed to the list.

Kind Regards,
Mike Kelly

Received on Friday, 16 October 2009 17:21:12 UTC