W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > January to March 2004

Re: DAV:unreserved - missing precondition?

From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Sun, 21 Mar 2004 10:21:37 -0500
To: ietf-dav-versioning@w3.org
Message-ID: <OF24AF65C6.3BD52C81-ON85256E5E.00174261-85256E5E.00545146@us.ibm.com>

I believe the point of a reserved checkout was to ensure that the
checkin would succeed.  But if we allow a reserved checkout to succeed
when there are currently unreserved checkouts against that activity,
if any of the unreserved checkouts are checked in, the subsequent
checkin of the reserved checkout will fail.

So doesn't that imply we should either:
- disallow a reserved checkout if there is already an unreserved checkout
or
- disallow the checkin of an unreserved checkout if there is a reserved 
checkout
?

Cheers,
Geoff

Alison wrote on 03/18/2004 08:08:27 AM:

> The 13.3.1 description of DAV:unreserved is more restrictive  than 
> DAV:one-checkout-per-activity-per-history enforces. The description 
> only allows for one checked-out resource for the activity, if that 
> checked-out resource has DAV:unreserved false. The precondition 
> however allows for multiple checked-out resources for the activity, 
> where at most one of these has a DAV:unreserved property of false. 
> 
> Given existing implementations of 3253 which may only enforce the 
> precondition rather than the description, I would suggest that the 
> description of DAV:unreserved is lined up with the precondition. 
> That is, at most one reserved (DAV:unreserved false) checked out 
> resource for an activity, but any number of unreserved (DAV:
> unreserved true) checked out resources for the same activity.
> 
> Geoffrey M Clemm wrote:
> Either interpretation is OK with me.  Do you (or anyone else) want
> this to be added?
> 
> Alison wrote on 03/12/2004 01:04:43 PM:
> 
> Section 13.3.1 of the spec says:
> 
> 
> 13.3.1 DAV:unreserved
> This property of a checked-out resource indicates whether the 
> DAV:activity-set of another checked-out resource associated with the 
> version history of this version-controlled resource can have an 
> activity that is in the DAV:activity-set property of this checked-out 
> resource.
> 
> The activity feature adds a checkout precondition:
> 
> 
> (DAV:one-checkout-per-activity-per-history): If there is a request 
> activity set, unless DAV:unreserved is specified, another checkout 
> from a version of that version history MUST NOT select an activity in 
> that activity set.
> 
> Should this precondition also cover the case where the checkout request 
> includes an activity and specifies DAV:unreserved, but the checkout 
> should fail because a checked-out resource already exists, with 
> DAV:unreserved false, and a DAV:activity-set value that contains the 
> checkout request activity?
> 
> 
> 
Received on Sunday, 21 March 2004 10:22:14 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:15:09 UTC