On 13 Nov 2006, at 12:03, Svensson, Lars wrote: > So, someone wants to access http://example.com/resources/foo which is > the URI for the resource "foo". In the accept-header, the client > indicates that it prefers application/rdf+xml . The server finds out > that it has a rdf/xml representation under > http://example.com/resources/foo.rdf and sends this back WITHOUT A > REDIRECT. Instead it sets the Content-Location header to > http://example.com/resources/foo.rdf to indicate that the returned > content was not at the requested URI, but at the specified location. > Similar of course for all other formats (like text/html). Yes, I think that's a good way to do content negotiation. > On the surface it seems clean, but something tells me that this is not > compatible with http-range-14 ... This is compatible *if* foo is an information resource (that is, its state can be expressed in a message). If foo is another kind of resources (e.g. a person), then you *must* do a 303 redirect to the location where a description of foo is available. You can 303-redirect to different locations based on accept headers. Post-httpRange-14, the only way to serve a description of a non-information resource without a second request is to use hash URIs. Which brings us back to the start of the thread: If http:// example.com/resources#Bob is a non-information resource, how to correctly serve both HTML and RDF descriptions? The problem is that the semantics of a fragment identifier depend on the content type. I wonder if this means we also have to do a 303 at http://example.com/ resources before we can serve a description of #Bob. Richard > > Can anyone please tell me I'm wrong? > > Lars > -- > Dr. Lars G. Svensson > Deutsche Nationalbibliothek > Informationstechnik > Adickesallee 1 > 60322 Frankfurt > http://www.d-nb.de/ >Received on Monday, 13 November 2006 13:41:04 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:22:44 GMT