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

Chris Kaler (ckaler@microsoft.com)
Thu, 5 Nov 1998 14:24:23 -0800 

Message-ID: <4FD6422BE942D111908D00805F3158DF0A75786E@RED-MSG-52>
From: Chris Kaler <ckaler@microsoft.com>
To: ietf-dav-versioning@w3.org,
Date: Thu, 5 Nov 1998 14:24:23 -0800 
Subject: RE: defining a versioned resource to be a "collection"



		From: Geoffrey M. Clemm [gclemm@tantalum.atria.com]
		...

		Having two ways of specifying a revision, i.e. either as a
		revision-URI or as a <versioned-resource-URI, revision-id>
pair, adds
		some amount of complexity to the protocol.  Since some
operations only
		return the revision-id, the client must then either store
the pair
		form, or must keep asking the server for the revision-URI
		corresponding to revision-id it just received.  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?  Since a "get" from a collection is defined
to be
		collection dependent, having the get do what we want for
versioned
		resources appears to be consistent with the definition of
collections.
		The various predecessor/successor/merge relations continue
to be revision
		properties.

		The only argument against doing so that I could find was in
Jim's first
		protocol proposal, and this was to handle the case where
some of the
		revisions of a versioned resource are located on other
servers.
		Since collection members can now be references, I don't see
that this
		presents a problem anymore.

		I re-read both the collection protocol paper, the URI RFC,
and all
		three protocol papers, and couldn't find anything that
argued against
		this simplification.  So although I continue to be worried
that I
		overlooked something obvious, I'll propose that we do so.
		...

The current proposal does return both elements of the "pair" you describe.
However, it seems my examples didn't show this.  There is a Location header
in HTTP that should/can return the target URI for an operation.  I would
expect this to return the versioned resource and the Revision-id header to
return the specific revision.

That having been said, 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?  

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.  

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 also think the collections approach assumes a basic linear history.  Once
you get into resource-level branching, do we represent the branch as another
collection?  If so, the collections of collections are going to get very
complex, very fast.

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.

Chris