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