Why MOVE isn't really defined as a COPY followed by a DELETE

The simplest definition of the MOVE method would probably be something like
"The result of a MOVE method is that the source URI is replaced with the
destination URI as a reference to the resource."

However this definition would imply certain things. For example, one would
expect that after a MOVE the resource referred to with the new destination
URI will behave exactly the way it behaved when it was named with the source
URI.

However this assumption ignores the realities of implementation. To pull out
the usual example, what happens if the source URI was in a CGI enabled
directory and the destination is not? Should the MOVE fail?

What if the MOVE will require, under the covers, that the resource be moved
from one server to another and the destination server doesn't support the
same live properties as the source? Should the MOVE fail?

All of this, of course, should sound very familiar. These are the exact same
problems that COPY has. Sort of.

In the last example we talked about a MOVE resulting in a resource being
moved from one server to another. If this were just a COPY then there would
now be two resources, one at the source server and one at the destination
server. But this is a MOVE, it should only result in a single resource. What
happened to the resource at the source server? Practically speaking its
file/program/etc. was deleted. This brings us to the Destroy header (see
<http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0111.html> for
more details). At the time that MOVE was being defined the Destroy header
was still in the spec. So there was a concern that since a MOVE could
potentially involve a DELETE it was important to be able to specify how the
DELETE was to be performed. The key word here is "potentially." There is no
requirement that a DELETE occur, but it could and if it does we need to be
able to control how it happens.

Which leads us back to the question of how to define MOVE. MOVE has the same
issues with resource behavior and live property support that COPY has. Just
like COPY, if you MOVE a resource you aren’t guaranteed it will behave the
same way at the destination as it did at the source. Just like COPY, the
only guarantees you have about properties after a MOVE are those provided by
the propertybehavior XML element. MOVE is more complicated than COPY,
however, because it also includes DELETE.

The general consensus of the authors was that the easiest way to define MOVE
was to inherit COPY and DELETE's definitions. In inheriting COPY the
author's intention was to guarantee the minimal functionality that COPY
provides, including support for the propertybehavior XML element. In
inheriting DELETE the author's intention was to provide support for the
Destroy header and other mechanisms relating to the DELETE method. It was
not the author's intention to require an actual COPY followed by an actual
DELETE, just to provide the same guarantees of minimal functionality.

This lead the authors to first define MOVE as "The logical equivalent of a
COPY followed by a DELETE performed atomically." The key word was "logical."
The word logical was supposed to mean that COPY and DELETE functionality was
inherited, not explicitly performed. Unfortunately the authors were too
subtle.

Judy Slein posted the classic example demonstrating the author's failure to
provide a sufficiently clear definition. Judy pointed out that if one had a
resource identified by a unique ID then moving the resource shouldn't cause
the ID to change. On the other hand, if one copied a resource then one would
expect the ID to change. So if a MOVE really is a COPY followed by a DELETE
then the resource at the destination would have a different ID because the
COPY would generate a new ID.

Of course the definition wasn't meant to result in the ID changing. We
though the word "logical" bought us a way out but readers who hadn't mind
melded with one of the authors had no way of knowing that.

The authors did try to clean things up by changing the definition to:

   The MOVE operation on a non-collection resource is the logical
   equivalent of a copy (COPY), followed by consistency maintenance
   processing, followed by a delete of the source, where all three
   actions are performed atomically.

We were trying to be very explicit that things like ID maintenance were
completely within the definition. In fact everything is in the definition.
The definition is not meant to exclude, only to provide basic guarantees.
When Judy came back with the same concern I knew we had failed. You see,
Judy knows more about WebDAV than anyone but the authors. If Judy didn't
understand what we intended then the only possible conclusion is that the
authors failed to provide a clear definition. I hope this paper will go a
little way toward fixing things. But obviously we will have to try again
when we move from Proposed to Draft.

Received on Sunday, 14 February 1999 02:05:23 UTC