W3C home > Mailing lists > Public > www-tag@w3.org > June 2006

Re: Updated Working Draft: Enabling Discovery Of Alternative Representations

From: T.V Raman <raman@google.com>
Date: Fri, 23 Jun 2006 09:18:52 -0700
Message-ID: <17564.5228.679519.513989@retriever.corp.google.com>
To: mnot@yahoo-inc.com
Cc: raman@google.com, www-tag@w3.org


Mark, I believe that using the vary header with location as you
suggest would be perfectly good for many situations. I have no
specific preference for redirect over the above; in either case,
i.e. content-neg vs redirect what I'd like to establish design
patterns for is the ability to discover that a particular URI is
in fact  has the capacity to support multiple
devices/representations.

What I mean is:
In an ideal world, where every URI is a "smart URI" and can give
you the right representation for your context,
you'd be able to happily follow *any* URI 
from *any* context and be assured of getting something reasonable.






Mark Nottingham writes:
 > The "default" HTTP way to solve the problem posed in section 2.1  
 > would be server-driven conneg; i.e., sending the correct  
 > representation in response to the request for http://example.com/ 
 > ubiquity/resource, along with the appropriate Vary header and a  
 > Content-Location header that can be used to determine where that  
 > specific representation can be found again.
 > 
 > If you're suggesting that redirection is better, it would be good to  
 > say why.
 > 
 > Cheers,
 > 
 > 
 > On 2006/06/22, at 6:07 AM, T.V Raman wrote:
 > 
 > >
 > > I've updated the document at
 > > http://www.w3.org/2001/tag/doc/alternatives-discovery.html
 > > Comments welcome.
 > >
 > > ToDos:
 > >
 > > I'd still like to draw a nice generic schematic diagram in the
 > > final section showing how a canonical URI can have various pieces
 > > of context bound into it to create a multiplicity of URIs.
 > >
 > > -- 
 > > -- T. V. Raman 
 > >
 > >
 > 
 > --
 > Mark Nottingham
 > mnot@yahoo-inc.com
 > 
 > 

-- 
-- T. V. Raman 
Received on Friday, 23 June 2006 16:19:09 GMT

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