W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > January to March 2001

RE: Move and copy, versioning and overwrite interactions

From: Clemm, Geoff <gclemm@rational.com>
Date: Sat, 10 Feb 2001 23:18:34 -0500
Message-ID: <3906C56A7BD1F54593344C05BD1374B101FC06BA@SUS-MA1IT01>
To: "Ietf-Dav-Versioning@W3. Org" <ietf-dav-versioning@w3.org>
I'd like to thank Lisa for producing this detailed document
describing her interpretations of the MOVE and COPY commands.
Although I believe that a tabular form is not the right way
to define functionality (it makes it easy for you to make all
sorts of special cases, rather than forcing you to define a
few simple orthogonal rules), it is an excellent way to test
whether the rules are consistent and understandable.

I looked over Lisa's document carefully, and there are just a 
few things that need to be fixed.
Rather than correct the document, I'd like to highlight the
rules in the protocol (or in WebDAV) that would relate to COPY/MOVE,
and in some cases, propose some additional wording
for the protocol, to emphasize these rules.
Then if at all possible, it would be a great test for this new
wording if Lisa could try to use these
rules to fix the table (i.e. this would test whether the document
now answers these questions on its own).

Lisa: If you do not have time for this exercise, let me know and
I can just post the fixes.


I propose we add the following paragraph to 2.1.1:  

"Note that a versionable resource and a version-controlled resource are not
new types of resources (i.e. they introduce no new DAV:resourcetype), but
rather are any type of resource that supports the methods and live
properties defined for them in this document, in addition to all the methods
and live properties implied by their DAV:resourcetype.  For example, a
collection (whose DAV:resourcetype is DAV:collection) is a versionable
resource if it supports the VERSION-CONTROL method, and is a
version-controlled resource if it supports the version-controlled resource
methods and live properties."

add the following new postcondition to COPY (2.1.2):

"(DAV:must-not-copy-versioning-property): A property defined by this
document MUST NOT have been copied to the new resource created by this
request, but instead that property of the new resource MUST have the default
initial value it would have had if the new resource had been created by a
non-versioning method such as PUT or a MKCOL."

and replace the DAV:preserve-history postcondition of MOVE (2.1.3) with:

"(DAV:preserve-versioning-properties): When a resource is moved from a
source URL to a destination URL, a property defined by this document MUST
have the same value on the resource at the destination URL as it had when
the resource was at the source URL."

I'd also like to emphasize the fact that unless we explicitly state
otherwise in the protocol, there is no behavior on PUT/COPY/MOVE beyond
what is specified in RFC 2616 and RFC 2518.  In particular, there is
no change to the Overwrite behavior beyond what is explicitly stated
in section 1.8 (i.e. no change to Overwrite behavior with MOVE).

So using the above rules, a resource loses all of its versioning
characteristics when it is COPY'd, but keeps all of its versioning
characteristics when it is MOVE'd.

Just as a hint, this means that there are not multiple tables to 
describe COPY behavior, since a COPY of any of the versioning
resources is required to be identical to copying a non-version-controlled
resource with the same dead properties and content.


-----Original Message-----
From: Lisa Dusseault [mailto:lisa@xythos.com]
Sent: Friday, February 02, 2001 12:22 AM
To: Ietf-Dav-Versioning@W3. Org
Subject: Move and copy, versioning and overwrite interactions

The latest versioning draft made some improvements in specifying how
MOVE and COPY behave in all the possible combinations of whether the
source is versioned, whether the destination is versioned, whether the
destination exists, and whether the overwrite header is present.
However, it wasn't sufficient for me to determine what every combination
would produce.  I had to make some assumptions, such as assuming that
when overwrite is False the client wants the method not to be performed
if the destination exists (rather than create a new version).

In doing this work, I built a set of tables, to make sure I captured
every option and combination and could compare them.

Authors, please review every cell in the tables and make sure this is
what you intended.  Also please review my stated assumptions.  It's
necessary to do both, because there may be assumptions that I was not
aware of and could not state; or misunderstandings.

Other DeltaV-ers, please glance at it and make sure your assumptions
correspond with mine!

Received on Saturday, 10 February 2001 23:10:42 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:46 UTC