W3C home > Mailing lists > Public > public-swbp-wg@w3.org > December 2005

RE: [VM] HTTP Cookbook, revised editor's draft

From: Miles, AJ \(Alistair\) <A.J.Miles@rl.ac.uk>
Date: Tue, 6 Dec 2005 18:45:53 -0000
Message-ID: <677CE4DD24B12C4B9FA138534E29FB1D9851AB@exchange11.fed.cclrc.ac.uk>
To: <public-swbp-wg@w3.org>

Hi all,

A technical note on the cookbook ...

Most of the recipes use _conditional redirects_, rather than content-negotiation per se, which is normally done via a type-map file, or via the MultiViews capability.

E.g. from recipe 3:

RewriteCond %{HTTP_ACCEPT} text/html [OR]
RewriteCond %{HTTP_ACCEPT} text/xml [OR]
RewriteCond %{HTTP_ACCEPT} application/xml [OR]
RewriteCond %{HTTP_ACCEPT} application/xhtml+xml
RewriteRule ^example3$ example3-content/2005-10-31.html [R=303]

RewriteRule ^example3$ example3-content/2005-10-31.rdf [R=303]

Why use conditional redirects, instead of using e.g. built in content negotiation support via MultiViews?

The main reason for not using MultiViews is that it requires that both the HTML and RDF files have the same file name, and are located in the same directory. Although this is the case for the example given in the cookbook, this is not the case for other vocabs. E.g. for both SKOS and DC the HTML documentation and the RDF are in completely different locations. The conditional redirect setup allows the recipe to be adapted to these cases where HTML and RDF content are located in different directories, or possibly on different servers.

An additional reason for preferring conditional redirects is that they avoid the situation where a single resource offers both HTML and RDF content, and references secondary resources identified via fragment identifiers. Because the semantics of a secondary resource within the HTTP URI scheme are determined by the content-type(s) available, there is plenty of potential for ambiguous interpretation and URI collision. Conditional redirects completely avoid any of this possible contention, and are therefore the safest option. 

Cheers,

Al.

> -----Original Message-----
> From: public-swbp-wg-request@w3.org
> [mailto:public-swbp-wg-request@w3.org]On Behalf Of Miles, AJ 
> (Alistair)
> Sent: 28 November 2005 16:56
> To: Thomas Baker; David Wood
> Cc: public-swbp-wg@w3.org
> Subject: RE: [VM] HTTP Cookbook, revised editor's draft
> 
> 
> 
> Hi Tom,
> 
> > I agree that we can and should recommend that people use time
> > stamps (or version numbers) in file and directory names but
> > suggest we take the explanation one step further.
> > 
> > I suggest we say somewhere that these time stamps are being
> > used as a social convention -- not in the expectation that
> > one should be able to extract or infer meaningful date (or
> > version) information from a pathname or URI string.
> 
> I'd be happy to add this caveat also.
> 
> N.B. I had some more thoughts about tightly scoped bite-size 
> chunks for VMTF work, see:
> 
> Change Management for RDFS/OWL Ontologies
> Part 1. Naming
> http://isegserv.itd.rl.ac.uk/cvs-public/~checkout~/swbp/vm/cha
> nge-management/part1.html
> Part 2. Metadata
> http://isegserv.itd.rl.ac.uk/cvs-public/~checkout~/swbp/vm/cha
> nge-management/part2.html
> 
> Cheers,
> 
> Al.
> 
> 
> 
Received on Tuesday, 6 December 2005 18:46:08 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:09:45 UTC