RE: CHECKIN and properties

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