W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > April to June 2001

RE: checked-out VCC: A new proposal

From: Clemm, Geoff <gclemm@rational.com>
Date: Mon, 21 May 2001 09:11:59 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B103041DC8@SUS-MA1IT01>
To: ietf-dav-versioning@w3.org
   From: Fay, Chuck [mailto:CFay@filenet.com]

   > From: Clemm, Geoff [mailto:gclemm@rational.com]

   > ....  Now it is true that if auto-checkout=locked-update is not
   > set, then a locked resource would never have been automatically
   > checked out, but this doesn't change/affect the meaning of
   > auto-checkin=locked-update.

   That was my underlying concern about the two-property approach:
   there are combinations of settings for auto-checkout and
   auto-checkin that produce odd results, or are just dysfunctional
   (as in the above example).  So in that sense, the use of these two
   properties is not as well-defined as auto-version was.

I don't believe this behavior is any more odd or dysfunctional than
the fact that CHECKIN fails if it is applied to a resource that is not
checked in, or that UNLOCK fails if it is applied to a resource that
is not locked.

   I'll leave it up to the list as to whether this is a problem.  It
   can certainly be avoided by using only combinations that match the
   old settings for auto-version.

I agree.

   My take on the mapping:

   never:
       auto-checkout = not set
       auto-checkin  = not set

   always-checkout-always-checkin:
       auto-checkout = locked-update, unlocked-update
       auto-checkin  = locked-update, unlocked-update

   always-checkout-when-unlocked-checkin:
       auto-checkout = locked-update, unlocked-update
       auto-checkin  = unlocked-update

   when-locked-checkout:
       auto-checkout = locked-update
       auto-checkin  = unlocked-update

You could also just leave auto-checkin unset in this case, since the
DAV:auto-checkout indicates that unlocked resource will not be
automatically checked out, but setting it to DAV:unlocked-update
is fine too.

   always-checkout-manual-checkin:
       auto-checkout = locked-update, unlocked-update
       auto-checkin  = not set

   > If a write-locked version-controlled resource was automatically
   > checked out because the DAV:auto-checkout property was
   > DAV:locked-update, and if the resource was still checked-out when the
   > write lock is removed (such as from an UNLOCK or lock timeout), then
   > the removal of the write lock is automatically preceded by a checkin
   > operation.

   This doesn't seem sufficient.  It would imply that "auto-checkin = not
set"
   would cause an automatic checkin when the write lock is removed.  I don't
   think this is what you intended.  That's why I included the specific
setting
   of auto-checkin in my suggested wording.

Actually, that was what I intended, i.e. if an auto-checked-out
resource is unlocked, it is automatically checked in before the unlock
(independent of the current settings of DAV:auto-checkin).

But one could make a case to allow this to be explicitly specified in
the DAV:auto-checkin setting, i.e. add a "DAV:unlock" value for
DAV:auto-checkin, and only do the auto-checkin on UNLOCK if this value
is set.  This also makes this behavior more explicit.

Any votes on whether we keep it the way it is, or whether we add an
explicit DAV:unlock value to DAV:auto-checkin?

Cheers,
Geoff
Received on Monday, 21 May 2001 09:12:43 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:41 GMT