- From: Yaron Goland <yarong@microsoft.com>
- Date: Wed, 12 Feb 1997 16:28:54 -0800
- To: "'Jim Whitehead'" <ejw@ics.uci.edu>, "'w3c-dist-auth@w3.org'" <w3c-dist-auth@w3.org>
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