RE: COPY def'n

I think this is a good idea. I would also like to see this issue touched-on in the introduction to the document (I think the link example would be a good example to cite in an introductory text).

Cheers
Dylan

-----Original Message-----
From:	Jim Whitehead [SMTP:ejw@ics.uci.edu]
Sent:	Saturday, February 21, 1998 4:18 AM
To:	'WEBDAV WG'
Cc:	Yaron Goland (E-mail)
Subject:	Re: COPY def'n

On key issue in this discussion on the semantics of COPY is the abstraction 
of the HTTP resource.  An HTTP resource is an object, with a series of 
methods it supports.  The parameters for the methods are specified by 
headers and by the request body.

When defining HTTP methods, the semantics of the method must be defined 
well enough to ensure interoperability.  However, since the state of the 
body of an HTTP resource has always been the "data secret" hidden by the 
resource abstraction (GET is carefully defined to be an on-the-wire 
representation of the state, not the state itself), a new method which 
implies a particular organization of the state of a resource can be viewed 
as violating the resource abstraction.

So, for example, specifying a COPY as an octet-for-octet copy implies that 
the state of the resource is organized as a linear sequence of octets. 
 However, I could easily imagine that a server which is an intelligent XML 
processor might organize the persistent state of a resource as an XML parse 
tree.  In this case, octet-for-octet is not particularly meaningful -- 
node-for-node makes more sense.

I think some people in this discussion (myself included) have viewed a 
resource as a file, and for files the notion of octet-for-octet makes a lot 
of sense.  However, for others participants in the discussion, the 
underlying store may not look anything like a file, and the notion of 
octet-for-octet does not apply.  Asking these kinds of stores to perform an 
octet-for-octet copy doesn't seem reasonable.

As a result, I'm starting to favor a definition for COPY along the lines of 
(this is intended to replace the first sentence of Section 7.10.1, with all 
other text in this section remaining unmodified).

If the environment at the destination is the same as at the source, the 
COPY method MUST create a duplicate resource which behaves exactly like the 
source resource.  Otherwise, if the destination environment is not the same 
as at the source, the COPY method SHOULD create a duplicate resource which 
behaves as closely as possible to the source resource.

This addresses my testability concerns, since a compliance suite will be 
able to create a collection where the environment (e.g., access control 
permissions, owner, etc.) is uniform enough to perform a meaningful test, 
yet still allows for meaningful copies across a wide range of repositories.

- Jim

Received on Monday, 23 February 1998 08:05:49 UTC