- From: Jim Whitehead <ejw@ics.uci.edu>
- Date: Wed, 24 Sep 1997 04:44:34 -0700
- To: "'Judith Slein'" <slein@wrc.xerox.com>
- Cc: "'w3c-dist-auth@w3.org'" <w3c-dist-auth@w3.org>
In re-reading this email, I realize that I never addressed several points. On Tuesday, September 16, 1997 9:42 AM, Judith Slein [SMTP:slein@wrc.xerox.com] wrote: > I think what is really desirable for (2) is for the client to be able to > specify in an INDEX request what information it wants about the members of > the collection. Collections are used for lots of different purposes, and > different properties of the members will be useful in different contexts. > However, this flexibility would make it impossible for the index to be > stored as a file, as DRP suggests -- it would have to be generated in > response to the client's request. This is an interesting suggestion. To date, the design of WebDAV has assumed that if a collection should return a different result, then it is a sub-class of the general collection type. As an example, versioned collections would return the normal INDEX information, plus predecessor, successor, and version identifier information. If DRP were to use WebDDAV INDEX, it would presumably want much less than the full set of properties returned for each member, perhaps only the name of each resource. Are there any other scenarios of use of INDEX information where it would be useful to allow the client to specify the set of information being returned? > To repeat a comment from Orem, we need to be clear about whether every URI > hierarchy will behave like a collection, or only collections that were > created using MKCOL. This mirrors the sentiment of the working group, and the next draft will have language which states that collection-like objects are be modeled as WebDAV collections, and the semantics of direct containment are be enforced by methods which create or delete resources. > Compound documents as collections: > > I would like to be able to use collections to represent compound documents. > Collections are ideal for this use because they let you operate on the > compound document as a whole (or they will once recursive operations for > collections are defined) and also to operate independently on any of its > members. But for collections to represent compound documents, three things > need to be standardized: > > 1. Support for ordering > > 2. A way to identify component types > > 3. A way to determine whether a collection represents a compound document > > 2 and 3 just require additional DAV properties: A ComponentType property > (with values such as CONTENT, DTD, STYLESHEET, etc.) that attaches to > members of compound document collections, and an IsCompoundDocument property > that attaches to collections. > > Support for ordering is the only significant change. It would involve the > following: > > INDEX would have to return the list of members in the correct order. (No > change in syntax is needed, just a change in what the server is required to do.) > > MKCOL with an entity body would have to treat the order of the items in the > entity body as significant. > > It needs to be possible to add both internal and external members at a > particular place in the sequence of members. It needs to be possible to > move a member from one place to another in the sequence. It may also be > useful to be able to delete members by sequence number as well as by URI. > On the one hand, this functionality seems simple to provide, and there is a large temptation to add it to the protocol. However, I'm not at all convinced that adding just this functionality would provide sufficient support for compound documents. My fear is that this will add extra functionality and complexity to the protocol, potentially causing a schedule delay. > It should be possible to version the collection as a whole, as well as any > of its members. The problem I see arising here is that it will prove difficult to determine which resources should be a member of a given collection. For example, how easy is it to make a collection which has all the "release 2" members, or only the latest versions of all members. This often ends up looking like a search for specific property values, with all the attendant complexity. > > Where members are versioned, there needs to be a way to define what a client > should get when it retrieves a member of the collection: A specific > version of the member, or the current published version of the member. At present, since each version of a resource is a separate resource, retrieving a member of a collection retrieves just the resource itself, which may be a member of a version tree. - Jim
Received on Tuesday, 23 September 1997 19:53:02 UTC