Collections

If there was a discussion period on collections, I missed it.  I do have
some comments to make, however, especially in light of DRP.

The DRP index differs from ours (aside from implementation details) in
several ways:

1. It describes the entire hierarchy, whereas ours describes only a single
level of the hierarchy.

2. It contains different information about each member of the hierarchy.

3. DRP hierarchies have only internal members, whereas WEBDAV allows both
internal and external members.

To reconcile the two specifications, I think (1) it would be very useful for
us to provide an index that describes the entire hierarchy rather than just
one level.  

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.

As for (3), I think that allowing external members of collections is
essential.  This is what allows the same resource to be shared by several
collections.

----------

Other comments on collections:

MKCOL was still pretty sketchy in the last draft.  When it gets defined in
more detail, it would be good if the entity body could be standardized to
define how clients would submit internal members and also external members.

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 has lots of implications, especially once
recursive operations are defined for collections.  Will those recursive
operations (MOVE, COPY, LOCK, etc.) work for all URI hierarchies, or only
for collections created with MKCOL?  A user can only figure out where he
wants to MOVE or COPY a resource if he can see the context he's operating
in.  We've made a stab at providing this with INDEX, but will it work for
all URI hierarchies, or only for collections created with MKCOL?  etc.

----------

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.

We would have to decide whether to add navigation methods like get next, get
previous.  We could just require clients to get the index and do the
navigation themselves.

------------

Versioning and collections:

It should be possible to version the collection as a whole, as well as any
of its members.

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.

--Judy

Name:			Judith A. Slein
E-Mail:			slein@wrc.xerox.com
Internal Phone:  	8*222-5169
External Phone:		(716) 422-5169
Fax:			(716) 265-7133
MailStop:		105-50C

Received on Tuesday, 16 September 1997 12:39:40 UTC