RE: Version-controlled collection resources - I am still missing something

   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