- From: Mike Kelly <mike@mykanjo.co.uk>
- Date: Fri, 16 Oct 2009 17:19:36 +0100
- To: public-html@w3.org
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