RE: collection with ordered members

Somewhere we have to say "enough." It is easy to add "Just one more
feature." However I do not believe it is appropriate to further complicate
the base DAV spec with a feature that no server, anywhere, document
management or otherwise, provides support for.

Furthermore, the issue is not one of a simple "magic bullet" and all of a
sudden all servers are able to support compound documents. There are two
steps to this process. First the server has to understand the particular
compound document format the client is using THEN the server has to support
the compound document features. So discovery MUST occur, first for the
document format and then for the compound document features.

Given the fact that this feature is brand new, given that it requires
discovery, I believe it is inappropriate to further complicate the
draft-ietf-webdav-protocol spec with it. It should be an extension spec and
support for the extension spec can be discovered at the same time that the
client discovers if the server supports the particular compound document
file format the client wishes to use.

			Yaron



> -----Original Message-----
> From:	Judith Slein [SMTP:slein@wrc.xerox.com]
> Sent:	Friday, October 24, 1997 6:49 AM
> To:	Yaron Goland
> Cc:	'Judith Slein'; Jim Davis; w3c-dist-auth@w3.org
> Subject:	RE: collection with ordered members 
> 
> 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 14:16:31 UTC