Re: Question about the On Linking Alternative Representations TAG Finding

Richard,
Thank you for adding value to the TAG finding I wrote with the
insights you have raised with this discussion -- see my summary
below.

I think the key insight in all of this is what you put very well:

A URI is a resource --- a generic resource has multiple
representations --- and in turn, each representation has  a URI.

The question you ask is an interesting one, and in terms of Web
Architecture in this regard, I've usually managed to preserve my
sanity in the last 15 years by following the maxim "dont look
more than one level deep in a recursive pattern".

As  a case in point, you could recreate this puzzle  on an axis
different from content-type --- e.g. language. So take a generic
resource U, do language negotiation,
U has alternative representations U_1, U_2, ..U_n. Further let's
now pull in content-type as well and  assume that each of the U_I
above are available in more than one content-type. Now, which
axis goes first in the process of resolving a resource to a
particular representation -- language or content-type? In cases
where the matrix  language-X-contentType is fully populated, and
where that matrix is symmetric, order does not matter. But in all
other cases, the order in which these axes are resolved will make
a difference.

Returning to your final question, where the user-agent does
content-negotiation, indicates a preference for one type, but
asks by URI for the other, I would say respect the URI. I dont
claim this to be *correct* in any sense, other than that I would
break the tie this way. Reasoning: The client, by asking for a
URI that directly resolves to a given representation has
essentially bypassed content-negotiation.

Another way to arrive at this conclusion with respect to
best-practice, and one that I believe the finding would benefit
from is:

If publishing a generic-resource, make sure that the URIfor that
generic resource does not collide with the URI for any one of its
representations.

At the time I wrote the finding, I did not assert the above
because that would actually fly in the face of general practice
on the Web, which is to let the URI for the generic resource also 
 serve as a proxy (alias) for the most commonly asked for
representation. 


In cases where the most commonly catered for client is a Web
browser with a live human at the other end,
I believe this practice of aliasing the URIfor the
generic-resource with the URI for the HTML version is still a
better choice from a user interface perspective, as well as for
avoiding one additional network round-trip.

So perhaps one option is to slightly water down what I asserted
above as might be useful to add to the finding --- and say that
if the user-agent sends preference about content-type, then
... As you rightly point out, web browsers have always sent
accept: */*  so any user-agent that sends a more refined accept
header can be  viewed as being something more modern than a
legacy Web browser.

Richard Cyganiak writes:
 > Thanks Raman.
 > 
 > Many people have added their bits to the thread. I will try to  
 > summarize the discussion and add a few thoughts of my own; and finally  
 > ask yet another question about a case that wasn't discussed yet.
 > 
 > 
 > 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.
 > 
 > 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.)
 > 
 > 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 */*.
 > 
 > 
 > 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?
 > 
 > Cheers,
 > Richard
 > 
 > 
 > On 31 Jul 2008, at 18:03, T.V Raman wrote:
 > 
 > > Thanks for the clarification -- I understand your specific
 > > question much  better now.
 > >
 > > I dont think you should respond with a 406 -- since that is the
 > > least helpful of all to the client.
 > >
 > > If the client requests resquest.html, and says it *only* accepts
 > > mime-type json,
 > > and you actually have a json representation available, it is
 > > really a toss-up as to what you would send. I myself tend to lean
 > > toward sending the JSON representation in this case, mostly
 > > because I beleive that the content-type should be trusted more
 > > than the infered mime-type available through the URL extension
 > > --- but that is a contentious topic in its own right.
 > >
 > > But this is a good issue that you have raised --- and is an
 > > example of two pieces of the HTTP Request being in conflict, with
 > > the specifications giving no clear   guidance as to how to break
 > > the conflict --- especially when taken in context of how
 > > user-agents behave at present.
 > >
 > > Richard Cyganiak writes:
 > >> Raman,
 > >>
 > >> My question was not at all about HTML vs. XHTML, Sebastien injected
 > >> that angle into the thread in a somewhat unhelpful way. I'm not
 > >> interested in hearing yet more people's opinions on the issue. I ask
 > >> for clarification of a detail in the TAG finding because I'm not sure
 > >> how to interpret the finding's intention.
 > >>
 > >> Let's say I have
 > >>
 > >> /resource      (generic information resource with HTML and JSON
 > >> variants)
 > >> /resource.html (a HTML specific URI)
 > >> /resource.json (a JSON specific URI)
 > >>
 > >> Now let's say I request /resource.json with an Accept header of
 > >> "Accept: text/html". What should happen?
 > >>
 > >> One opinion is that the JSON should be served anyway, because the URI
 > >> identifies a specific variant.
 > >>
 > >> Another opinion is that the HTML should be served, or redirected to,
 > >> because that's what the client asked for and the server has it
 > >> available.
 > >>
 > >> (A third opinion is that 406 should be answered, as suggested by
 > >> Sebastien.)
 > >>
 > >> What I'm asking for is simply a clarification of the advice in the
 > >> spec. Did you intend that there be content negotiation on the
 > >> representation_i URIs?
 > >>
 > >> Cheers,
 > >> Richard
 > >>
 > >>
 > >> On 31 Jul 2008, at 17:21, T.V Raman wrote:
 > >>
 > >>>
 > >>>
 > >>> I'm a bit confused at this point by the question.
 > >>>
 > >>> Could you flesh out your example?
 > >>>
 > >>> HTML  is a particularly good example, depending on how much you
 > >>> know about your HTML  resource.
 > >>>
 > >>> Though there is much debate on this, in my experience,
 > >>> wel--formed  XHTML survives well when served either as text/html
 > >>> or application/xml+xhtml.
 > >>>
 > >>> So if you have a resource under your control whose  content you
 > >>> know is well-formed XHTML that you would rather serve as
 > >>> application/xml+xhtml, but you also know that many legacy agents
 > >>> only accept text/html
 > >>> In that case, you might definitely want to  check the accept
 > >>> header and serve the appropriate response.
 > >>>
 > >>> Sebastien Lambla writes:
 > >>>>> Is it ever appropriate to configure content negotiation on the
 > >>>>> *representation-specific URIs*? So, if someone requests the
 > >>>>> specific  URI
 > >>>>> for representation_1, but the Accept header indicates a
 > >>>>> preference  for
 > >>>>> representation_3, should content negotiation kick in and
 > >>>>> representation_3
 > >>>>> be served instead?
 > >>>>
 > >>>> If your url is the representation-specific one, then the conneg
 > >>>> would fail
 > >>>> if the content-type of /resource.html is text/html and the Accept:
 > >>>> only
 > >>>> contains application/xhtml+xml, as the representation is not the
 > >>>> resource
 > >>>> and the url you requested is the one of the representation, not the
 > >>>> resource. I would return a 406.
 > >>>>
 > >>>> I'd understand the reasoning as being that if you dereference /
 > >>>> resource.html
 > >>>> and get a 200 you can assert it is a document, if you were to
 > >>>> conneg to
 > >>>> another url from the specific url you loose that assertion as
 > >>>> defined in
 > >>>> httpRange-14
 > >>>>
 > >>>> Sebastien Lambla
 > >>>
 > >>> -- 
 > >>> 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
 > >>>
 > >>>
 > >
 > > -- 
 > > 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
 > >

-- 
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:23:25 UTC