defining a versioned resource to be a "collection"

Geoffrey M. Clemm (
Tue, 3 Nov 1998 09:53:48 -0500

Date: Tue, 3 Nov 1998 09:53:48 -0500
Message-Id: <9811031453.AA27562@tantalum>
From: "Geoffrey M. Clemm" <>
Subject: defining a versioned resource to be a "collection"

Rather than send out all my comments on the latest protocol draft
in one "bulk mailing", I decided to break in up into several smaller
threads for easier automated thread management (if anyone feels this
is a mistake, please let me know).

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

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.