Re: defining a versioned resource to be a "collection"
David G. Durand (dgd@cs.bu.edu)
Tue, 1 Dec 1998 09:27:12 -0400
Message-Id: <v04011701b2899c5e006f@[24.0.249.126]>
In-Reply-To: <4FD6422BE942D111908D00805F3158DF0A75786E@RED-MSG-52>
Date: Tue, 1 Dec 1998 09:27:12 -0400
To: ietf-dav-versioning@w3.org
From: "David G. Durand" <dgd@cs.bu.edu>
Subject: RE: defining a versioned resource to be a "collection"
At 6:24 PM -0400 11/5/98, Chris Kaler wrote:
>We would also have to add the notion of a "default" member to a collection.
>That is, if I do a GET on the versioned resource, which is just a
>collection, which resource within the collection do I return (this is the
>PIN method, but the semantics are a little broader now -- not that this is
>bad).
As I understand collections, the result of doing a GET is server defined
(as we have properties for accessing metadata and contents information for
collections). Defining that a particular kind of collection responds to GET
in a particular way is exactly the kind of thing this leeway was intended
to support. I don't see it as a bizarre new thing, but a sensible leverage
of a method we created for just this kind of case!
>When building Web sites, the inter-page links are very important. I believe
>people want to be able to version their sites without requiring a lot of
>link updating to occur.
I agree with this very strongly, but I don't think your mechanism is the
only (or even the best) way to ensure this.
Any method of mapping a specific version of a resource to a specific part
of a URL tree will accomplish this. Configurations do this (and there may
be different levels of complexity). The use of default versions is _surely_
separate from the use of a special header, since the default version is
produced when the header is omitted (or perhaps has a special value).
The real problem with the header technique is that it duplicates a
mechanism that we'll need anyway (the ability to create a URL that
represents a particular revision of a versioned resource). We must have
such URLs to support version-specific links (e.g. for copy-editing
applications). So why create a duplicate mechanism involving new HTTP
headers that duplicates that functionality.
You articulate a the case for configurations or some other way of getting a
"friendly" default-version URL space. That's separate from the Header/URL
issue.
>That is, I should be able to create different
>branches and have my links still work by passing in headers to qualify the
>URI. By introducing namespace changes to refer to the branches and versions
>(or even configurations), you force the links to have to change.
The headers are a red herring, I think. To restate the requirement:
"We must be able to have a URL space where HTML links (relative URLs at
least, and perhaps absolute ones) will not be broken because the HTML files
are stored in versioned resources."
-- David
_________________________________________
David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com
Boston University Computer Science \ Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams
--------------------------------------------\ http://www.dynamicDiagrams.com/
MAPA: mapping for the WWW \__________________________