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

Geoffrey M. Clemm (gclemm@tantalum.atria.com)
Mon, 9 Nov 1998 12:29:07 -0500


Date: Mon, 9 Nov 1998 12:29:07 -0500
Message-Id: <9811091729.AA01226@tantalum>
From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: ckaler@microsoft.com
Cc: ietf-dav-versioning@w3.org
In-Reply-To: <4FD6422BE942D111908D00805F3158DF0A75786E@RED-MSG-52> (message
Subject: Re: defining a versioned resource to be a "collection"

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

   From: Chris Kaler <ckaler@microsoft.com>

      From: Geoffrey M. Clemm [gclemm@tantalum.atria.com]
      ...
      Since a collection is
      a canonical way of specifying a resource as some base resource
      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 collection
   resource itself.  Does it become a collection of collections?  

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

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

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

One could, but I wouldn't recommend doing so.  I'd just make the branch
be a property of the revision.  In particular, this branch-as-property
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 very
   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 change.

I assume that you are referring to the problems of handling absolute
inter-page links in the presence of namespace versioning?  (Relative
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 solve
this problem, you need to pass around a "version-selection" header
that indicates what revision should be selected from each of the
versioned collections back to the root of the URI space.  In addition,
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 then
upgrading all methods to treat absolute URI's in a document as
relative URI's wrt the specified workspace URI.

Cheers,
Geoff