RE: Issue: MOVE Semantics

Thanks for your post Judy. It helped me realize that the section of the
WebDAV Book of Why entitled "A Short history of copy and move" should really
be titled "A short history of copy". More than that, it helped me to realize
that the post really sucked. I swear it was funny when I wrote it, but
apparently in a "you had to be there" kind of way. Anyway I broke it out
into three separate posts which I have put up on the list.

Your post also helped me find this gem of a post (if I do say so myself =)
which goes into the gory details of exactly why locks are lost on moves -
http://lists.w3.org/Archives/Public/w3c-dist-auth/1997JulSep/0177.html. As
you will see, the definition of MOVE did not play a part in the decision
requiring that locks be lost on MOVEs.

Also, while working on my response to your question I found Larry's post on
how to structure WebDAV which sparked this post
(http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0130.html).

In fact, your post sparked so much new material that I just released the V.
Alpha 2 version of the WebDAV Book of Why
(http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0129.html)

As to your specific points, I hope my post on MOVE
(http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/) helped to
explain the relationship of COPY and DELETE to MOVE and why the authors
wrote the language the way they did. More importantly I hope it explains why
the definition of MOVE does not prevent the functionality you are seeking.

			Thanks,
						Yaron

> -----Original Message-----
> From: Slein, Judith A [mailto:JSlein@crt.xerox.com]
> Sent: Friday, January 22, 1999 9:08 AM
> To: 'WebDAV'
> Subject: Issue: MOVE Semantics
> 
> 
> In the current version of the WebDAV specification, MOVE is 
> defined as COPY
> followed by DELETE.
> 
> I believe that this definition causes enough problems that we should
> consider changing it.
> 
> As Jim Davis recently pointed out (in his comments on
> draft-hopmann-collection-props-00.txt), it causes problems 
> for IDs.  We
> expect that when an object is moved, it will have the same ID.  But we
> expect that when an object is copied, the new copy will have 
> a distinct ID.
> We can't have both these semantics if MOVE is defined as COPY 
> followed by
> DELETE.
> 
> Other properties will have similar problems, like creation date.
> 
> An attempt to MOVE a resource to its same location will result in the
> resource being deleted.  (This forced the advanced 
> collections protocol to
> invent a new method for changing the position of a resource in a
> collection's ordering, when we might otherwise have been able 
> to use MOVE.)
> 
> It is probably this definition that forced the spec to say 
> that locks are
> lost after a MOVE, a counterintuitive result.  I would expect 
> an object that
> was locked before a MOVE still to be locked after the MOVE.
> 
> Could we just say that after a MOVE, the resource is 
> accessible through the
> URI in the Destination header, and is no longer accessible through the
> request-URI of the MOVE request, and get rid of the 
> definition in terms of
> COPY and DELETE?
> 
> --Judy
> 
> Judith A. Slein
> Xerox Corporation
> jslein@crt.xerox.com
> (716)422-5169
> 800 Phillips Road 105/50C
> Webster, NY 14580
>

Received on Sunday, 14 February 1999 18:24:21 UTC