- From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
- Date: Mon, 5 Feb 2001 01:14:25 -0500 (EST)
- To: ietf-dav-versioning@w3.org
From: "Jim Whitehead" <ejw@cse.ucsc.edu> Date: Wed, 31 Jan 2001 17:42:14 -0800 Section 2.2 and Section 2.3: Is it a MUST level requirement that a core versioning server support all of the properties in sections 2.2 and 2.3? I.e., MUST a version-controlled resource have all of the Section 2.2 properties defined upon it (well, really, all that are appropriate for its checked out/checked in state), and MUST a version resource have all of the Section 2.3 properties defined on it? If so, I couldn't find a place that explicitly states this. I'll add the statement that the properties defined by core or an option are REQUIRED for core or that option. Section 2.2.3: It seems like, most of the time, the server will be setting the value of DAV:predecessor-set, and except for merges, or adding to the server-computed value, the client shouldn't try to write to this property. Is this correct? If so, it would be nice to capture this in Section 2.2.3, so client writers have a better expectation about how this property works. There are common cases when branching is disallowed but multiple checkouts are allowed where a client will be updating the predecessor set. I believe this is better handled in the scenarios document or FAQ, and not in the protocol document itself. Section 2.2.5: This seems underspecified to me. There are really two parameters here, resource is write-locked/unlocked, and autoversion status of when-unlocked, and when-locked. ... I'll fix this. In particular, there are really only 3 interesting combinations: DAV:always-checkout-always-checkin DAV:always-checkout-when-unlocked-checkin DAV:when-locked-checkout Also, what happens when the resource is write-locked, and the value of DAV:auto-version is changed from when-locked to when-unlocked? Is a version automatically created upon successful completion of the PROPPATCH (because there would already be an active CHECKOUT due to the lock, and the when-locked condition)? Yes, the postcondition of UNLOCK does not depend on the current state of the DAV:auto-version property. Section 3.2: CHECKIN takes a version-controlled resource, and turns it into a version resource which is a copy of its body and dead properties. Properties that must exist on a checked-out version-controlled resource are: DAV:checked-out DAV:predecessor-set DAV:precursor-set DAV:auto-version Which of these properties should be transferred over to the version resource created by CHECKIN? My guess is: DAV:checked-out: no Yes, properties that are not explicitly stated as being transferred are not transferred. DAV:predecessor-set: yes DAV:precursor-set: yes Oops! Forgot this one ... will fix. DAV:auto-version: no At the very least, this issue is not currently addressed in the specification (except for DAV:predecessor-set). DAV:precursor-set behavior is described implicitly (by the existence of the property on a version resource) -- I think it should be made more explicit, in the description of CHECKIN. It is, in the DAV:initialize-version-content-and-properties postcondition. The text describing the (DAV:checked-in) postcondition should explicitly note that the properties being discussed are on the version-controlled resource, and not the version resource. Will do. Cheers, Geoff
Received on Monday, 5 February 2001 01:15:22 UTC