RE: Question about the On Linking Alternative Representations TAG Finding

see my earlier response. I think splitting hairs between resource
and representation only works "so far".

Booth, David (HP Software - Boston) writes:
 > > From: Richard Cyganiak
 > > [ . . . ]
 > > First, it seems clear that this is not a question of Web architecture,
 > > but rather a question of good practices. Neither setup violates Web
 > > architecture, but different setups might be more or less useful to
 > > clients.
 > 
 > Well, the HTTP spec sounds pretty clear about what should happen, so it may be a violation of the HTTP spec to return the wrong thing, but I don't view it as a violation of the architecture.
 > 
 > >
 > > Second, it seems worth to mention terminology. The original resource
 > > (at /resource in my example) is the "real" resource we are interested
 > > in. It's a "generic resource" because it is available in different
 > > formats. The format specific URIs identifies specific *variants*,
 > > which are *representations* of this original resource. However, by
 > > assigning URIs to those representations, we are turning the
 > > representations into resources of their own right. (Because, by
 > > definition, everything that is identified by a URI is a resource.)
 > 
 > That is close, but not quite correct.  The format-specific URIs identify related *resources*.  They do *not* identify representations, even though they may well return the same kind of representations when you GET from them.  In fact, a format-specific URI could even return different representations in the same format at different times or in response to different requests.  For example, a PDF URI could return one PDF representation at one time and a different PDF representation at another time.
 > 
 > In theory one *could* mint a URI to denote a particular representation -- a representation returned in response to a particular request on a particular URI at a particular time -- but that is not what's being discussed in your scenario.
 > 
 > >
 > > Third, many people have voiced this opinion: If the client indicates
 > > that it does not support the format available at this URI, then HTTP
 > > 406 should be sent. (This is clearly a SHOULD, not a MUST, according
 > > to the language in RFC 2616.)
 > >
 > > Fourth, I would like to point out that the case discussed under
 > > "third" does not arise if the client is a normal *Web browser*,
 > > because they all have */* in their accept headers and thus indicate at
 > > least *some* support for *every* format. But the case does arise with
 > > other HTTP clients that do not accept */*.
 > 
 > Good point.
 > 
 > >
 > >
 > > I'm still unclear about one particular case: What should be done if a
 > > client indicates support for several formats, but prefers one over the
 > > others; and the URI is specific to one of the non-preferred formats?
 > > Example:
 > >
 > >      Accept: text/html;q=1.0, application/rdf+xml;q=0.5
 > >
 > > This client supports HTML and RDF, but it prefers HTML over RDF.
 > >
 > > If /resource.rdf is accessed, what should happen? The URI is
 > > specifically for the RDF variant. So we have a conflict between the
 > > resource (which is available in RDF) and the preference of the browser
 > > (which would rather have HTML than RDF). Should the server ignore the
 > > preference and send RDF anyway?
 > 
 > My opinion: Yes.  The user is probably testing the URI in a generic browser, didn't bother to change the Accept header, and want wants to see the RDF.
 > 
 > 
 > 
 > 
 > David Booth, Ph.D.
 > HP Software
 > +1 617 629 8881 office  |  dbooth@hp.com
 > http://www.hp.com/go/software
 > 
 > Statements made herein represent the views of the author and do not necessarily represent the official views of HP unless explicitly so stated.

-- 
Best Regards,
--raman

Title:  Research Scientist      
Email:  raman@google.com
WWW:    http://emacspeak.sf.net/raman/
Google: tv+raman 
GTalk:  raman@google.com, tv.raman.tv@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc

Received on Wednesday, 6 August 2008 16:26:41 UTC