- From: Judith Slein <slein@wrc.xerox.com>
- Date: Fri, 24 Oct 1997 06:49:12 PDT
- To: Yaron Goland <yarong@microsoft.com>
- Cc: "'Judith Slein'" <slein@wrc.xerox.com>, Jim Davis <jdavis@parc.xerox.com>, w3c-dist-auth@w3.org
At 01:32 PM 10/23/97 PDT, Yaron Goland wrote: >What happens if you DELETE a compound document on a server which models >compound documents as a collection but does not support TREE methods? >That is why modeling compound documents as a collection is just wrong. > You are right that collections can't represent compound documents effectively unless the TREE methods are implemented. In my heart of hearts, I think those methods should be mandatory. Anyhow, if they are optional, that makes support for compound documents optional -- possible only on servers that have the TREE methods. >Simply PUT the document to the server. If the server understands the >structure of the compound document then INDEX will work on the document. >You can even PUT into its namespace to add members. At that point you >add headers to specify ordering information. This works on ALL DAV >servers, does not require support of TREE methods, fully supports >ordering, and doesn't require we change a line of the DAV spec. I agree that it's possible to represent compound documents, given the infrastructure WebDAV provides. But what I want is for a way of representing compound documents to be standardized. I think we would have what we need if we add ordering to collections, and define a body for MKCOL. Or if you prefer it, we could define a body for PUT that servers should understand as a compound document, assigning a URL to each component as well as to the whole, and requiring them to support INDEX for these documents. We could define the headers to be used for ordering. We could define how MOVE, COPY, and DELETE work for such compound documents. It just seems more straightforward to work collections, since we've got all these basic behaviors defined for them. --Judy
Received on Friday, 24 October 1997 09:45:52 UTC