defining a versioned resource to be a "collection"
Geoffrey M. Clemm (gclemm@tantalum.atria.com)
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" <gclemm@tantalum.atria.com>
To: ietf-dav-versioning@w3.org
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
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.
Cheers,
Geoff