RE: checked-out VCC: A new proposal

Overall, I prefer the previous DAV:auto-version property and its settings,
because the four possible settings were all well-defined.  With the proposed
property tuple (DAV:auto-checkout, DAV:auto-checkin) replacing
DAV:auto-version, there appear to be thirty-two possible settings of the
tuple.  This seems like an unnecessary jump in complexity, if all that was
needed was one more setting for DAV:auto-version, namely
"always-checkout-manual-checkin".

(Incidentally, if we go back to the DAV:auto-version property, I recommend
renaming "DAV:when-locked-checkout" to
"DAV:when-locked-checkout-when-unlocked-checkin", in order to be consistent
with the other setting names.  It should cover both checkout and checkin
explicitly like the other setting names.)

Specific issues with the tuple proposal:

1. It's not clear to me how the server should behave for some of the
settings for (DAV:auto-checkout, DAV:auto-checkin), such as
(DAV:unlocked-update, DAV:locked-update) or (not set, DAV:locked-update
and/or DAV:unlocked-update).

2. What is the meaning of the DAV:unlock setting for DAV:auto-checkin?  It
was listed in the formal definition but never referenced in the text.

3. The description of the checkin-on-unlock operation doesn't seem complete.

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

Another clause concerning the setting of DAV:auto-checkin seems necessary to
make the above statement true:

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

Depending on the intended semantics for DAV:unlock, verbiage about
DAV:unlock may have to be added as well.

Again, however, I would prefer extending the simpler "DAV:autoversion"
property over resolving these issues with the new tuple proposal.

--Chuck Fay 
FileNET Corporation, 3565 Harbor Blvd., Costa Mesa, CA 92626 
phone:  (714) 327-3513, fax:  (714) 327-5076, email:  cfay@filenet.com

> -----Original Message-----
> From: Clemm, Geoff [mailto:gclemm@rational.com]
> Sent: Thursday, April 12, 2001 3:39 PM
> To: ietf-dav-versioning@w3.org
> Subject: RE: checked-out VCC: A new proposal
> 
> 
>    From: Tim_Ellison@uk.ibm.com [mailto:Tim_Ellison@uk.ibm.com]
>    Subject: Re: checked-out VCC: A new proposal
> 
>    I agree that this conforms to the 'minimum change to the spec'
>    criteria -- and it is even a defendable position (bonus!)
> 
>    I do not object.
> 
> While investigating the new "auto-checkout-manual-checkin" value for
> DAV:auto-version, it appeared to me that things could be made
> significantly clearer if we replace the DAV:auto-version property with
> a DAV:auto-checkout and DAV:auto-checkin property.  This lets us
> specify auto-checkout behavior independently from auto-checkin
> behavior, which is what we need/want for 
> "auto-checkout-manual-checkin".
> 
> Is this OK?
> 
> Cheers,
> Geoff
> 
> --------------------------------------
> 
> 
> 3.2.2	DAV:auto-checkout 
> 
> When a modification request (such as PUT/PROPPATCH) is applied to a
> checked-in version-controlled resource, if the resource is
> non-write-locked and the DAV:auto-checkout property is
> DAV:unlocked-update, or if the resource is write-locked and the
> DAV:auto-checkout property is DAV:locked-update, the request is
> automatically preceded by a checkout operation.
> 
> A server MAY refuse to allow the value of the DAV:auto-checkout
> property to be modified.
> 
> <!ELEMENT auto-checkout ANY>
> ANY value: A sequence of elements with at most one
> DAV:unlocked-update element and at most one DAV:locked-update
> element.
> <!ELEMENT unlocked-update EMPTY>
> <!ELEMENT locked-update EMPTY>
> 
> 3.2.3	DAV:auto-checkin 
> 
> When a modification request (such as PUT/PROPPATCH) on a checked-in
> version-controlled resource has been automatically preceded by a
> checkout operation, if the resource is non-write-locked and the
> DAV:auto-checkin property is DAV:unlocked-update, or if the resource
> is write-locked and the DAV:auto-checkin property is
> DAV:locked-update, the request is automatically followed by a checkin
> operation.
> 
> If a write-locked version-controlled resource was automatically
> checked out because the DAV:auto-checkout property was
> DAV:locked-update, a removal of the write lock (such as from an UNLOCK
> or lock timeout) is automatically preceded by a checkin operation.
> 
> A server MAY refuse to allow the value of the DAV:auto-checkin
> property to be modified.
> 
> <!ELEMENT auto-checkin ANY>
> ANY value: A sequence of elements with at most one
> DAV:unlocked-update element, at most one DAV:locked-update
> element, and at most one DAV:unlock element.
> <!ELEMENT unlocked-update EMPTY>
> <!ELEMENT locked-update EMPTY>
>

Received on Tuesday, 17 April 2001 18:20:43 UTC