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

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?)

>  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;

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.

>  otherwise, the DAV:version MUST be
>  the DAV:root-version of the version history.

I am trying to write up a spec for the programmers to work on.
Currently my plan is to implement WebDAV but not the DeltaV protocol.
However, we do support versioning, so we will make a higher level
API to our versioning system compatible with DeltaV to make it
easy to glue in the protocol later when there are more clients
around. Hence my need to understand exactly what goes on. I have
to explain it to someone else! :-)

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. 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?".

Getting there...

Alan

Received on Monday, 2 July 2001 19:25:08 UTC