W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > July to September 2006

Re: DAV:cannot-copy-collection-version precondition for COPY

From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Tue, 22 Aug 2006 21:40:59 -0400
To: werner.donne@re.be
Cc: ietf-dav-versioning@w3.org
Message-ID: <OFCFB0CC4A.5F9CFF67-ON852571D3.0008B13C-852571D3.00093FA9@us.ibm.com>
COPY has to obey the semantics defined for it by RFC-2518 (so that an 
RFC-2518 client can interoperate with an RFC-3253 server), or must fail.
Since a collection version is a resource with no members, the result of a 
successful COPY of a collection version would have to be the creation of a 
destination resource with no children.  Since this is unlikely to be the 
behavior that a versioning client would want, the COPY request is defined 
to fail.

Cheers,
Geoff


Werner wrote on 08/22/2006 04:24:25 PM:
> I thought that a version of a collection represented the state of
> that collection at a certain point. So the 
version-controlled-binding-set,
> which is a collection version property, contains the binding names
> that correspond to the members of the collection at that version.
> If collection /a has members b and c at a certain point, then the
> version of the collection corresponding to this would have binding
> names b and c.
> 
> Given a version of a VCR, a system can find that VCR. If our VCR is
> collection /a and if we have binding names b and c in the collection
> version, we can reconstruct /a/b and /a/c. Now we have enough to
> create a new collection with members b and c.
> 
> I don't find that very strange. What is the difference between copying
> a collection version to another collection, leading to a new version
> controlled collection in the latter, and copying a version controlled
> collection with a label header. Precondition 
must-select-version-in-history
> in section 8.7 results in some collection version to be used for the
> copy. I could also have specified that collection version directly in
> the request URI.
 
> Geoffrey M Clemm wrote:
> > It sounds like you are suggesting that the result of the copy depend 
on
> > what is in the target of the copy?  That would be very strange "copy"
> > behavior (i.e. the result of the copy should only depend on the source
> > of the copy).  Collection versions are for use by "merge" and 
"update".
 
> > Werner Donné <werner.donne@re.be> wrote on 08/22/2006 10:59:59 AM:
> >> A collection version has the names of its version controlled bindings
> >> and their version history. It is then possible to find the checked-in
> >> version of the members, which is what is used also when a collection
> >> is copied.

> >> Geoffrey M Clemm wrote:
> >> > A collection version does not have enough information in it to 
produce a
> >> > sensible copy, since it only records the version history of its 
members,
> >> > not the versions.  So a collection version is useful for updating a
> >> > configuration, but is not useful for creating a new configuration
> >> > (that's what baselines are for).

> >> > Werner wrote on 08/22/2006 06:34:16 AM:
> >> >> Why should the request fail if the source is a collection version?
> >> >> It seems to me that any version is as good as the checked-in 
version
> >> >> to copy from.
Received on Wednesday, 23 August 2006 01:41:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:44 GMT