RE: Collections

I would argue that if the client is specifying what is returned then it
is not an INDEX, it is a search. There will be a separate working group
set up to define how one does that with DAV.
	Yaron

> -----Original Message-----
> From:	Judith Slein [SMTP:slein@wrc.xerox.com]
> Sent:	Wednesday, September 24, 1997 7:04 AM
> To:	ejw@ics.uci.edu
> Cc:	'Judith Slein'; 'w3c-dist-auth@w3.org'
> Subject:	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 17:55:07 UTC