- From: Jim Amsden <jamsden@us.ibm.com>
- Date: Tue, 19 Jun 2001 07:31:42 -0400
- To: ietf-dav-versioning@w3.org
Lisa says: >>A direct read of this paragraph combined with deltaV draft 15 (and your implication) would indicate that you can't issue a VERSION-CONTROL method on a lock-null resource. That's bogus. A "write locked null resource" is there so that the creator can do all the write operations and state changes they need before making the resource visible to everybody. So, I suggest that VERSION-CONTROL (and perhaps other methods like CHECKOUT, MKWORKSPACE...) should be explicitly allowed by DeltaV to be done on write locked null resources, and that the spec define a precondition that can be returned if the server decides not to allow operations on write-lock resources.<< The purpose of lock null resources was to provide an atomic operation for creating and locking a new resource. It was not to control visibility of a resource until the creator is ready to "release" it to the community. Lock null resources do appear in PROPFIND of collections with dept 1 or infinity, and do respond to PROPFIND themselves. This is a hack solving a specific instance of a problem without coming up with a general solution (which would probably require Web transactions). What problem would be solved by allowing versioning of lock null resources? What would it mean? What would be the contents of the root revision? These are all questions that will be difficult and arbitrary to answer resulting in the current approach to handling lock null resources.
Received on Tuesday, 19 June 2001 07:31:49 UTC