- From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
- Date: Tue, 23 Mar 2004 20:55:15 -0500
- To: ietf-dav-versioning@w3.org
Renaming a feature only introduces complexity, because for interoperability, new clients and servers would have to support both the old and the new names. So I would suggest we not do that. (The reason it was defined in the negative is that the default behavior should be "reserved", since making the checkout unreserved introduces the possibility that you will not be able to checkin if another checkin for that version for that activity is done before you. If a server/client wants non-branching behavior, they would use the DAV:checkout-fork and DAV:checkin-fork mechanisms, not DAV:unreserved. DAV:unreserved is only needed to "reserve" a particular activity (aka branch). Cheers, Geoff Edgar wrote on 03/23/2004 03:24:56 PM: > Alison Macmillan <alison.macmillan@oracle.com> wrote: > > 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. > First I wonder why we think negative. I think it would be more natural > to make an editorial change to DAV:reserved and depreceate DAV:unreserved. > Also here DAV:unreserved is tied to the activity feature. I feel it already > makes sense without activities (Which for me implies that there is a single > implicit default activity).
Received on Tuesday, 23 March 2004 20:59:41 UTC