RE: Collections

Thanks for your responses, Jim.  My comments are interspersed.

At 04:44 AM 9/24/97 PDT, Jim Whitehead wrote:
>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?

Yes, I can imagine lots of them:

If we use collections for variants, you would want to get back for each
variant the properties related to content negotiation -- language, media
type, character set, some quality estimate, etc.

Some universities are starting to put reserve readings online.  Supposing
there is a collection for each course, an index might return author, title,
length in pages, sequence number, date by which it should be read.

An industry analyst like Gartner Group might make reports available (for a
price) online, and a view of their image management collection might show
report title, length, publication date, abstract, and price.

Etc.

>
>> 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.

Good.

>
>> 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.
>

I don't want to cause a schedule delay.

On the other hand, if this functionality is simple to provide, I believe it
would support large, useful classes of compound documents -- those with
sequential or hierarchical structures.  These are the ones that document
management systems try to support today.

>
>> 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.

On reflection, I see that interactions between collections and versioning
push us into the area of configuration management, which we are trying to
avoid taking on.  I know that as you develop the versioning draft you are
keeping an eye on interactions with collections and will try to keep them as
simple and intuitive as possible.  I'll look forward to seeing the result.

--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 Wednesday, 24 September 1997 10:01:18 UTC