RE: Issues: Copy/Move

Burden of Finding the Source is on the Client - We can actually define a
WC in the error message to say "You can't copy me but you may be
interested in my source at URL..."

CopyHead & MoveHead - Nuke 'em.

Jim's General Specification - This is mega overkill for the requirements
doc but I believe it has a place in the protocol specification. We need
to get really nitty gritty on our definitions if we are to be
interoperable and I believe this is a start. So you have just been
elected to re-write the copy/move/delete sections of the protocol
specification. Congratulations. =)

		Yaron

>-----Original Message-----
>From:	Jim Whitehead [SMTP:ejw@ics.uci.edu]
>Sent:	Tuesday, February 11, 1997 4:06 PM
>To:	w3c-dist-auth@w3.org
>Cc:	ejw@ics.uci.edu
>Subject:	Issues: Copy/Move
>
>
>>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
>
>

Received on Wednesday, 12 February 1997 19:42:52 UTC