W3C home > Mailing lists > Public > www-tag@w3.org > January 2003

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

From: Jeremy Dunck <ralinon@hotmail.com>
Date: Wed, 08 Jan 2003 16:52:20 -0600
To: gtn@rbii.com, www-tag@w3.org
Message-ID: <BAY1-F686SgICImAZVD000066ec@hotmail.com>

>From: Gavin Thomas Nicol <gtn@rbii.com>
>
>On Tuesday 07 January 2003 08:29 pm, Jeremy Dunck wrote:
<snip>
> > still make it too expensive to accomplish.  We don't suppose that since
> > people don't commonly fly to work, there's no interest in that.
>
>Technology without adoption is dead, and you may as well bury it... it 
>doesn't
>matter how good it might appear to be. SGML had the SGML declaration which
>allowed you to do all kinds of nifty things to the syntax of SGML, and to
>it's interpretation of character encodings. Time proved it wasn't worth it,
>and so both XML and HTML are defined with a single SGML declaration... a 
>kind
>way of putting it out to pasture.
>
>Maybe lack of interest, and the complications people have with content
>negotiation hint that it's not finding a sweet spot?

Has anyone tried to find a sweet spot?  I understand that feature 
negotiation, as described in RFCs 2295 and 2703 are probably too general and 
abstract to be immediately applicable, but certainly applications of the 
described framework could be useful.

I see that Apache subsetted 2295 (doing MIME and Language based negotation) 
but not the rest of it.  Do you really feel that this is the sweet spot?  I 
would agree for content differentiated by MIME, but with XML-everything, 
perhaps the sweet spot is moving?

I think that MIME maps nicely to file extensions, and Language is a thing 
people generally grasp, and so those two things were easily negotiated (and 
mapped easily to the existing file system).

> > I feel that for a particular conceptual resource, there may well be
> > multiple representations, but I also feel that each of those
> > representations might deserve its own URL.
>
>That's the heart of it. If I have
>
>   <img src="http://foo.bar.com/foo.jpg"/>
>
>and the server suddenly starts sending me a PIC representation, I'd likely 
>be
>unhappy.

I agree (since the common expectation is that an URL ending in "jpg" is a 
JPEG image), but this tight binding to a particular representation is 
exactly what negotiation was meant to address.  Must all UAs support JPEG?

Would you be similarly annoyed if you had this:
  <img src="http://foo.bar.com/foo"/>
which returned JPG to your UA, but returned SVG to some else's?

Or do you mean that people don't generally care enough about the possibility 
of alternates to be bothered?

Thanks for the feedback.
  Jeremy

_________________________________________________________________
MSN 8 helps eliminate e-mail viruses. Get 2 months FREE* 
http://join.msn.com/?page=features/virus
Received on Wednesday, 8 January 2003 17:52:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:15 GMT