Re: defining a versioned resource to be a "collection"

Chris Kaler (
Mon, 30 Nov 1998 11:54:05 -0800

Message-ID: <4FD6422BE942D111908D00805F3158DF0A757937@RED-MSG-52>
From: Chris Kaler <>
To: "'Geoffrey M. Clemm'" <>
Date: Mon, 30 Nov 1998 11:54:05 -0800
Subject: RE: defining a versioned resource to be a "collection"

I don't this approach works for one of my canonical cases.  I have a Web
site that I update using DAV.  We now have a DAV server that supports
versioning.  Some of my clients are using non-versioning DAV clients, some
are using versioning-aware DAV clients.  Both clients should be able to see
and operate on the structure of the Web.  

I think getting this right adds more complexity to the clients which is
where I think we should be simplifying.  I guess I don't understand why
passing a version token is bad.  You will likely be holding a lock token
anyway, so why is this so much of a burden?

Possibly a disconnect here is they way I think of versioned resources.
Personally, I like the idea that the URI namespace refers to versioned
resources and that you specify the revision-id header to refer to a specific
revision, otherwise the request is against the versioned resource (or the
default revision).  Of course you can always obtain a URI for a specific
revision.  I think this approach makes clients much easier to build and
makes the protocol transition from non-versioning to versioning easier.  As
well, I prefer not to define server-side structure whenever possible as it
ties the hands of the server writer.


		-----Original Message-----
		From:	Geoffrey M. Clemm []
		Sent:	Monday, November 09, 1998 9:29 AM
		To:	Chris Kaler
		Subject:	Re: defining a versioned resource to be a

		Chris raises several good questions.  In order to answer
them, I will
		in several cases refer to a proposal for handling versioned
		that I posted earlier today to this mailing list (it's
subject was
		"versioned collections: a proposal".

		   From: Chris Kaler <>

		      From: Geoffrey M. Clemm []
		      Since a collection is
		      a canonical way of specifying a resource as some base
		      extended by some unique (wrt that base resource)
identifier, why don't
		      we just define a versioned-resource to be a
collection, and each
		      revision to be a member of that collection identified
by what we have
		      been calling the revision-id? 

		   ... I think your approach has some problems.  First, I
		   don't understand how you would handle the versioning of a
		   resource itself.  Does it become a collection of

		Yes.  (See the "versioned collections" article for details).

		   As for complexity, I'd argue it is a wash.  You trade the
complexity of the
		   pair of information for the complexity of inserting extra
collections into
		   the namespace.

		Inserting extra collections into the namespace does not
increase the
		complexity of the protocol, while requiring a pair of
identifiers to
		identify a revision resource does (e.g. the new header
needed to specify
		the revision id, and extending the method semantics to use
or ignore
		the new header).  This is certainly something we could cope
with if we
		had to, but I'd need to see some real benefit before paying
the price.

		   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

		I don't see why we would have to define in general the
notion of a
		"default" member of a collection.  We define the notion for
		resources, and that isn't affected by whether the versioned
resource happens
		to be a collection (of revisions).

		   I also think the collections approach assumes a basic
linear history.

		Why?  A standard collection is just a set with identifiers
for the members.
		This implies nothing about the linear nature of the history
(this is determined
		from the predecessor/successor properties of the revisions).

		   you get into resource-level branching, do we represent
the branch as another

		One could, but I wouldn't recommend doing so.  I'd just make
the branch
		be a property of the revision.  In particular, this
		approach allows you to support the "change-set" approach
with no change
		to the protocol.

		   If so, the collections of collections are going to get
		   complex, very fast.

		Another reason not to do so.

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

		I assume that you are referring to the problems of handling
		inter-page links in the presence of namespace versioning?
		inter-page links require no additional headers).

		I agree that this is an important problem, but I do not
believe it can
		be effectively solved by passing around a "revision-id".  To
		this problem, you need to pass around a "version-selection"
		that indicates what revision should be selected from each of
		versioned collections back to the root of the URI space.  In
		you need to indicate when you want a revision, and when you
want a
		working resource.

		In my proposal for handling versioned collections, this
problem would
		be addressed by passing around a "workspace" header, and
		upgrading all methods to treat absolute URI's in a document
		relative URI's wrt the specified workspace URI.