- From: Fay, Chuck <CFay@filenet.com>
- Date: Fri, 2 Feb 2001 15:18:25 -0800
- To: Jim Whitehead <ejw@cse.ucsc.edu>, ietf-dav-versioning@w3.org
Jim Whitehead wrote on Wednesday, January 31, 2001 5:42 PM: > Section 2.2.5: > > This seems underspecified to me. There are really two parameters here, > resource is write-locked/unlocked, and autoversion status of > when-unlocked, and when-locked. I agree that all the combinations need to be covered by the spec. Moreover, section 2.1.2 only talks about auto-version being "set" and doesn't differentiate among the possible settings of auto-version. Both problems need to be fixed. Geoff Clemm's 1/13/01 email sketched out his intent for the semantics of the four possible settings for auto-version: > nothing (no auto-versioning) > DAV:when-locked (auto-checkout when locked) > DAV:when-unlocked (new version when unlocked) > DAV:when-locked, DAV:when-unlocked (both) In an attempt to fill in Jim's table, I have tried to expand Geoff's sketch, based on Geoff's other messages around the same time. It's useful to recall that if the VCR is checked out at the time of the PUT or PROPPATCH, the auto-version property is ignored, and there is no auto-versioning. That leaves the case when the VCR is checked-in at the time of the PUT or PROPPATCH, with the following interpretation of the value of auto-version: nothing - no auto-versioning DAV:when-locked - auto-checkout when write-locked, buffer changes until unlock request, then auto-checkin - error when unlocked (at time of PUT or PROPPATCH) DAV:when-unlocked - create new version; i.e., auto-checkout, modify, auto-checkin (must supply lock header if VCR write-locked) DAV:when-locked, DAV:when-unlocked - auto-checkout when write-locked, buffer changes until unlock request, then auto-checkin - create new version when unlocked; i.e., auto-checkout, modify, auto-checkin Note that when-unlocked does *not* mean auto-version only when the VCR is unlocked, whereas when-locked does in fact mean auto-version only when the VCR is write-locked. This inconsistency makes the naming somewhat misleading, but I haven't come up with anything better that also works in combination in the fourth case. This interpretation of when-unlocked is critical for versioning systems that require all versionable resources to be under version control, but don't support storing intermediate state on the server between checkout and checkin. Such systems cannot support the CHECKOUT option, because it requires storage of intermediate state. Nor can they support the when-locked flavor of auto-versioning, for the same reason. So they are reduced to depending on the when-unlocked flavor of auto-versioning in core versioning, with the above interpretation covering all VCRs, regardless of lock state. --Chuck Fay FileNET Corporation, 3565 Harbor Blvd., Costa Mesa, CA 92626 phone: (714) 327-3513, fax: (714) 327-5076, email: cfay@filenet.com
Received on Friday, 2 February 2001 18:23:12 UTC