Re: Question about the On Linking Alternative Representations TAG Finding

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

Received on Thursday, 31 July 2008 17:04:00 UTC