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

Re: DAV:unreserved - missing precondition?

From: Alison Macmillan <alison.macmillan@oracle.com>
Date: Mon, 22 Mar 2004 11:46:49 +0000
Message-ID: <405ED229.2050808@oracle.com>
To: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Cc: ietf-dav-versioning@w3.org
The second option looks better to me, i.e.

- disallow the checkin of an unreserved checkout if there is a reserved checkout

as I think the first condition would need to be:

- disallow a reserved checkout if there is already an unreserved checkout, and disallow an unreserved checkout if there is already a reserved checkout.

which restricts parallel development.


Geoffrey M Clemm wrote:

>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
>- disallow the checkin of an unreserved checkout if there is a reserved 
>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 
>>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 Monday, 22 March 2004 06:47:30 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:48 UTC