Re: Issues: Copy/Move

I like this a lot!

A couple of comments:

Postcondition 3 on COPY seems weak to me.  I would expect something more
like "Independence: A modification to the resource at the dest-URI must not
cause any modification to the resource at the source-URI, and vice-versa."
Is there a reason for stopping short of this?

Now that we've introduced metadata into the picture, we also need to take a
look at DELETE.  It will need some similar extensions to deal with metadata.

Since we are making it possible for metadata to be shared by multiple
resources, the server may find that it cannot comply with a user's request
to move metadata.  Should the server in that case refuse to do the move at
all, or do it but not move the metadata, do it and fix up the links to the
mdetadata?

I'm still pretty confused about what should happen for version trees and
collections.

--Judy

At 04:06 PM 2/11/97 PST, Jim Whitehead wrote:
>
>>NAME SPACE MANIPULATION
>>
>>(Section 7 of WebDAV specification.)
>>
>>1. Semantics of copy and move.  At the Irvine meeting there was a detailed
>>discussion of whether a copy (move) is an octet for octet copy (move), a
>>manipulation of the namespace, or both.  One suggestion was to have a copy
>>(move) be an octet for octet copy (move) of the source of a resource.
>>
>>2. Link behavior on copy/move.  At present, a copy/move will attempt to
>>keep links with the resource across a copy/move.  However, since predefined
>>links may vary across a namespace, the links on a source may vary from
>>links on the destination.  What should the specification say/proscribe
>>about link properties across a copy/move?
>
>A better approach for defining the semantics of copy and move is to specify
>what postconditions must hold after a copy/move operation, rather than
>specifying exactly what operation occurs during a copy/move.  The latter,
>operational approach is currently used in the specification.  A proposal
>for a precondition/postcondition based approach is given below:
>
>First, some definitions:
>
>Let a resource be a set of {  body, metadata }.  In the current DAV and
>HTTP specifications, metadata consists of links, and response entity
>headers.  Furthermore, metadata can be represented as a set of {
>user-metadata , system-metadata} representing the difference between
>metadata created by a user-agent, and metadata created by a non-user-agent.
>
>This makes a resource a set of { body, { user-metadata, system-metadata} }
>
>COPY:
>
>Let the interface to the copy operation be:
>
>  copy(source-URI, dest-URI, copy-meta, overwrite)
>   source-URI: URI
>   dest-URI: URI
>   copy-meta: boolean
>   overwrite: boolean
>
>The semantics of copy can be defined as:
>
>Copy is an operation which has the following preconditions and postconditions:
>
>Preconditions:
>
>1. The source-URI must map to an existing resource.
>2. If overwrite is false, the dest-URI must not map to an existing resource.
>
>Postconditions:
>
>1. Namespace: The body of the resource at the dest-URI must be octet for
>octet identical to the body of the resource at the source-URI.
>
>2. Metadata: If copy-meta is true, the user-metadata of the resource at the
>dest-URI must be octet for octet identical to the user-metadata of the
>resource at the source-URI.  If copy-meta is false, the user-metadata of
>the resource at the dest-URI is the null set.
>
>3. Independence: A modification to the resource at the dest-URI must not
>imply as a necessary accompaniment an identical modification to the
>resource at the source-URI, and vice-versa.
>
>
>MOVE
>
>Let the interface to the move operation be:
>
>  move(source-URI, dest-URI, move-meta, overwrite)
>   source-URI: URI
>   dest-URI: URI
>   move-meta: boolean
>   overwrite: boolean
>
>Move is an operation which has the following preconditions and postconditions:
>
>Preconditions:
>
>1. The source-URI must map to an existing resource.
>2. If overwrite is false, the dest-URI must not map to an existing resource.
>
>Postconditions:
>
>1. Namespace: The body of the resource at the dest-URI must be octet for
>octet identical to the body of the resource at the source-URI prior to the
>move.
>
>2. Metadata: If move-meta is true, the user-metadata of the resource at the
>dest-URI must be octet for octet identical to the user-metadata of the
>resource at the source-URI prior to the move.  If move-meta is false, the
>user-metadata of the resource at the dest-URI is the null set.
>
>3. Removal: The dest-URI does not map to an existing resource.
>
>
>How do these definitions work on existing Web content classes?
>
>1. Non-server processed resources (e.g. vanilla HTML, bitmaps, etc.).
>Since each of these resources typically only holds one location in the URL
>namespace, and since there is no distinction between source and processed
>output (as holds for server-side includes), the definitions of copy and
>move work well.
>
>2. Server-processed resources, one source resource, one or more processed
>resources (e.g., server-side includes).  In this case, there is a
>distinction between URL_proc, the set of URLs which give the locations
>where the processed output may be retrieved, and URL_src, the single URL
>where the source resource resides.  While a copy operation could work on
>any member of URL_proc (creating a snapshot copy of the results of the
>processed resource), it probably makes sense for servers not to allow this
>operation.  A move operation on any member of URL_proc would fail, because
>it would be impossible to satisfy the removal postcondition.  A copy or
>move operation on URL_src would definitely work.
>
>3. CGI processors.  Since a CGI can potentially be passed the copy or move
>operation, no guarantees can be made about the correct processing of copy
>or move as applied to CGI processor code.  Ideally, a CGI processor should
>behave like in case 2 above.
>
>4. Multiple source resources, multiple processed resources.  Similar to
>case #2, a copy on a member of URL_proc would work, but should be
>discouraged, while a move on a member of URL_proc would fail.  In this
>case, URL_src has more than one member, but a copy or move on a member of
>URL_src would still work.
>
>Notes:
>
>- These definitions of copy and move place the burden of discovering the
>source (i.e., a member of URL_src) on the client.  In most cases, this
>should be possible by following a predefined link from a member of URL_proc
>to a member(s) of URL_src.
>
>- The examples assume a single stage of processing between source and
>processed output, and it assumes this processing is taking place in the
>server.  However, the definitions of copy and move appear to be capable of
>modeling more complicated cases.
>
>- The definitions assume that the server controls a portion of the metadata
>(system-metadata) and the user-agent controls a portion of the metadata
>(user-metadata).  The user-agent has no control over the system-metadata
>during a move or copy.  It is expected that system-metadata will vary
>across a server's namespace.  The user-agent does, however, have complete
>control over the user-metadata.
>
>>3. Copyhead/Movehead.  These methods were proposed to give a client the
>>means to discover, prior to performing a copy or a move, what is likely to
>>happen when the copy/move is performed.  At the Irvine meeting, a counter
>>model of "the client requests an operation, then discovers from the
>>response and from querying the state of the server what occurred."  While
>>this model is currently supported by copy and move, the issue remains
>>whether this model is sufficient, or needs to be augmented with copyhead
>>and movehead (and if these methods are kept, what should they be called?)
>
>I propose COPYHEAD and MOVEHEAD be stricken from the specification.  Would
>anyone like to step up and defend them?  It is my belief that removing
>these methods reflects the current sentiment of the group.
>
>- Jim
>
>
>
>
Name:			Judith A. Slein
E-Mail:			slein@wrc.xerox.com
Internal Phone:  	8*222-5169
External Phone:		(716) 422-5169
Fax:			(716) 265-7133
MailStop:		128-29E

Received on Wednesday, 12 February 1997 19:04:10 UTC