- From: Clemm, Geoff <gclemm@rational.com>
- Date: Mon, 2 Jul 2001 20:52:27 -0400
- To: DeltaV <ietf-dav-versioning@w3.org>
From: Alan Kent [mailto:ajk@mds.rmit.edu.au] On Mon, Jul 02, 2001 at 10:41:27AM -0400, Clemm, Geoff wrote: > So following text should have appeared in section 14.9 (additional > VERSION-CONTROL semantics for version-controlled collections): > > Additional Postconditions: > > (DAV:new-version-controlled-collection): If the request body > identified a collection version, the collection at the request-URL > MUST contain a version-controlled internal member for each > DAV:version-controlled-binding specified in the > DAV:version-controlled-binding-set of the collection version, where > the name and DAV:version-history of the internal member MUST be the > DAV:binding-name and the DAV:version-history specified by the > DAV:version-controlled-binding. I assume this is applied recursively down the project collection tree. (And if so, should it be explicitly stated?) Yes, that would probably be worth making explicit. I will add that in. > If the internal member is a member of > a workspace, and there is another member of the workspace for the same > version history, the DAV:version of the internal member MUST be the > DAV:version of that other member; otherwise, the DAV:version MUST be > the DAV:root-version of the version history. I thought I had read somewhere that a single workspace must never have two occurrences of a resource from the same configuration or else ambiguities can result in some of the operations. Eg: if UPDATE was used to change one of the two VCR's but not the other, then you did a baseline operation. Actually, the requirement is that only one version-controlled resource from a given version history can be a member of a given workspace. This sentence should be rewritten to make that clear. How about: If the internal member is a member of a workspace, and there is another member of the workspace for the same version history, those two members MUST identify the same version-controlled resource. I am finding, as a matter of interest, that for each operation I need to define semantics of operations on collection and non-collection resources separately in almost every case. Yes, the presence of "members" for a collection means that you almost always have to say what the meaning of an operation is for those members, in addition to the effect on the collection "itself". I don't see this as a problem, but it may be useful to keep in mind the next time someone does a read through of the spec - "does this section make sense for both types of resources?". And because versioning introduces other kinds of resources (version histories, baselines, activities), and other "flavors" of existing kinds of resources (version-controlled, baseline-controlled, version, working resource), you have to extend this question for many of the basic operations (MOVE, COPY, DELETE, LOCK, UNLOCK) to say "does this section make sense for all the 2518 and deltav categories of resources". Keeps one on one's toes (:-). Cheers, Geoff
Received on Monday, 2 July 2001 20:53:08 UTC