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

Re: content negotiation anti-principle

From: Jeremy Dunck <ralinon@hotmail.com>
Date: Wed, 08 Jan 2003 17:04:35 -0600
To: gtn@rbii.com, www-tag@w3.org
Message-ID: <BAY1-F153ZxjbP3SIGY000064a5@hotmail.com>

>From: Gavin Thomas Nicol <gtn@rbii.com>
>I'm not sure that there is a good answer here... the minimalist answer is 
>remove content negotiation altogether (and I'll note that much of the
>original rationale for it no longer applies).

What was the original rationale for negotation?  To me, it is a way to make 
resource dependencies less brittle, and to allow variance in UA support.

How does this no longer apply?  Am I missing something?

>That doesn't resolve the "what is a resource?" issue though.... the only 
>to solve that is to have some means to bind a URI to a given 
>and that flies in the face of current wisdom.

I don't think it does.  From [Generic Resources]:

As an example, successively specific resources might be
  The Bible
  The Bible, King James Version
  The Bible, KJV, in English
  A particular ASCII rendering of the KJV Bible in English

Each resource may have a URI.

To me, that means that while "The Bible, KJV, in English" is likely to 
appeal to the general public as a single resource, a particular rendering (a 
representation of the original resource) still may have (I read "deserves") 
a URI.

And I agree with the sentiment.  Basically, while it is useful for me to 
link to an image, it is less useful for me to link to an SVG representation 
(which doesn't work in your browser), so I'll link the image as a resource, 
and you can negotiate which specific representation you need.

The missing piece, to me, is making it obvious to the linker what, exactly, 
a particular resource represents, so that they can intelligently choose 
which (less generic) URI they might find most useful.


[Generic Resources]

MSN 8 helps eliminate e-mail viruses. Get 2 months FREE* 
Received on Wednesday, 8 January 2003 18:05:06 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:32:36 UTC