RE: Collections

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