RE: Question about the On Linking Alternative Representations TAG Finding

> 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.

Received on Tuesday, 5 August 2008 20:48:25 UTC