- From: Yaron Goland <yarong@microsoft.com>
- Date: Wed, 24 Sep 1997 14:54:48 -0700
- To: "'Judith Slein'" <slein@wrc.xerox.com>, ejw@ics.uci.edu
- Cc: "'w3c-dist-auth@w3.org'" <w3c-dist-auth@w3.org>
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