Re: DAV:unreserved - missing precondition?

Would it also be clearer if the precondition:

  DAV:one-checkout-per-activity-per-history

was renamed to

  DAV:one-reserved-checkout-per-activity-per-history?

Alison.

Geoffrey M Clemm wrote:

>OK, that makes sense to me.
>
>I'll make this update to both RFC-3253bis as well as JSR-147,
>if there are no objections.
>
>Cheers,
>Geoff
>
>Alison wrote on 03/22/2004 06:46:49 AM:
>
>  
>
>>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.
>>
>>Alison.
>>    
>>
>
>  
>
>>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
>  
>
>>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?
>>
>>
>>
>>
>>
>>
>>    
>>
>
>  
>