Re: Resources and representations (was RE: Subgroup to handle semantics of HTTP etc?)

Booth, David (HP Software - Boston) wrote:
>> From: Williams, Stuart (HP Labs, Bristol)
>> [ . . . ]
>> The HTTP range question simply asks what sort of things can
>> an HTTP URI refer to?
>> And the answer given is 'any kind of thing' (whether or not
>> their is a '#' in the spelling of the URI).
> True, but to be clear, the WebArch also imposes some additional constraints that depend on: (a) what kind of resource is denoted; and (b) the media type returned when the URI is dereferenced.  In particular:
I don't know (a) but for (b) media type is about the *representation* 
not the resource.  Its purpose is to tell the client how to interpret 
the bit-stream, not the resource. 
>  - If the URI denotes a non-information resource and the URI has a fragment identifier and a 200 response is returned when the racine (the part before the '#') of the URI is dereferenced, then the media type returned must be a media type that permits its fragment identifiers to denote arbitrary resources.   For example, you may return RDF but *not* (currently) HTML, because the media type for RDF permits a fragment identifier to denote anything, whereas in HTML a fragment identifier denotes a location within the document.
I hold a different view.  The fragment of a representation is still a 
representation.  It bears a relationship, but non-deterministic, to the 
resource that the URI denotes. 
>  - If the URI denotes a non-information resource and the URI does NOT have a fragment identifier then the server should not return a 200 response when the URI is dereferenced.  (Instead it should return a 303 response, redirecting to an information resource where a description of the original non-information can be obtained.)
You can, but you don't have to, for any resource.  303 is not wrong in 
principle, but it is an inferior engineer design.  It offers nothing in 
return except slowing the network, making browser's bookmark and caching 
difficult.  Just don't do it! Just return a *representation* of the 
resource in whichever the content type that the client prefers.  If a 
client confuses the *representation* with your *resource*, that is not 
because you did something wrong but because s/he has interpreted your 
message wrong - to which you have no control whatsoever.


Received on Wednesday, 24 October 2007 15:50:50 UTC