Re: Value of content negotiation? [was RE: content negotiation anti-principle]

>From: Gavin Thomas Nicol <gtn@rbii.com>
>On Thursday 09 January 2003 12:32 am, Mark Nottingham wrote:
<snip>
>The main failure within the current world of content negotiation is that 
>you
>have no way to say "I want a specific representation of a resource" from 
>the
>application level. For example, if I do this:
>
>    <a href="foo.html">foo.html</a>
>
>there is an implicit requirement that the representation returned be in
>text/html (and of course, entities in XML are even more fragile), but I 
>have
>no way of *forcing* that at the application level. So despite all the
>possible (if underused) benefits of negotiation in terms of robustness, it
>also engenders a degree of fragility.

I agree with your example (that common usage expects text/html given the 
example A), but assuming people clearly understood what "foo", as a separate 
URI, identified, I don't think too many have cause to link -specifically- to 
the text/html representation of it.


>Now there are two ways to deal with the problem: really look to see if 
>content
>negotiation is *really* alive and well (my experience is that it is not 
>used
>widely, your mileage may vary), and if not, to toss it.

I may be Don Quixote, but I don't think it's impossible to make it an 
affordable approach, and that cost (currently) is what's killing common 
server-side content negotiation.

>The other way is to
>bridge the gap between the application and protocol such that the 
>application
>has *finer* control over the returned representations.
>
>About the closest thing I can think of to the latter is the "charset"
>attribute on the <A> element in HTML. Though it's purpose is really 
>somewhat
>different, it is used to specify metadata about the representation of the
>resource being linked to.

In the special case that such a restriction -is- desirable, I think it's 
reasonable to provide negotiation hints (something like <a 
desiredTypes="text/html application/xhtml+xml text/xml "href="foo">foo</a>).

That'd allow the publisher to tell the browser what to accept, but it would 
still give the server control on actual type resolution.

I was really hoping to accomplish the important goals without change to any 
markup languages, because any changes made should work with the existing web 
content.

I think this is a chicken and egg problem... I'll try to think of a way to 
deliver the chickens.  ;)

I'm not saying that changes to markup aren't worth doing, but I do feel 
those are corner cases.

What makes you feel that lack of control over the returned representation is 
the stumbling block?  It's my perception that authors would be surprised 
only if they didn't understand that the content was negotiated.

Since they don't have the metadata to inform them, they are commonly 
surprised.  To me, that doesn't indicate a need to strictly control what's 
returned from a particular URI, but rather the need to make information 
available to the author so that an informed linking decision can be made.

  -Jeremy

_________________________________________________________________
Help STOP SPAM: Try the new MSN 8 and get 2 months FREE* 
http://join.msn.com/?page=features/junkmail

Received on Thursday, 9 January 2003 10:11:13 UTC