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

Re: Re (2): DAV:unreserved - missing precondition?

From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Tue, 23 Mar 2004 20:55:15 -0500
To: ietf-dav-versioning@w3.org
Message-ID: <OF62F18113.CC416A55-ON85256E61.0009B879-85256E61.000A7DBA@us.ibm.com>

Renaming a feature only introduces complexity, because for 
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).


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 
> Also here DAV:unreserved is tied to the activity feature. I feel it 
> makes sense without activities (Which for me implies that there is a 
> implicit default activity).
Received on Tuesday, 23 March 2004 20:59:41 UTC

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