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: Tue, 23 Mar 2004 20:32:33 -0500
To: ietf-dav-versioning@w3.org, JSR-147-EG@JCP.ORG
Message-ID: <OFF88D0D1E.86803858-ON85256E5F.006F5E83-85256E61.000869D3@us.ibm.com>

We could make this change for JSR-147 (and I will do so),
but for backward compatibility, we should leave the name
of this precondition alone for RFC-3253.

Cheers,
Geoff

Alison wrote on 03/22/2004 09:12:25 AM:
> 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?
> 
> 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.
> 
> 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?
> 
> 
> 
> 
> 
> 
> 
> 
> 
Received on Tuesday, 23 March 2004 20:37:22 UTC

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