Re: DAV:unreserved - missing precondition?

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.

Alison.

Geoffrey M Clemm wrote:

>Either interpretation is OK with me.  Do you (or anyone else) want
>this to be added?
>
>Cheers,
>Geoff
>
>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 Thursday, 18 March 2004 08:10:09 UTC