- From: Clemm, Geoff <gclemm@rational.com>
- Date: Sat, 10 Feb 2001 23:18:34 -0500
- 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. Cheers, Geoff -----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. http://www.sharemation.com/~milele/public/Versioned-MOVE-COPY3.htm 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! Lisa
Received on Saturday, 10 February 2001 23:10:42 UTC