- From: Mike Kelly <mike@mykanjo.co.uk>
- Date: Thu, 22 Oct 2009 11:01:12 +0100
- 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