RE: Ordered Collections

I've submitted a new draft of the collection requirements to
Internet-Drafts, so they should be available in a few days.

I made the following changes, mostly in response to Jim Whitehead's recent
comments:

1.  I added a paragraph discussing server-maintained vs. client-maintained
orderings, and stated explicitly that the requirements are only for
client-maintained orderings.

2.  I added a requirement (3.2.2) stating that collections are not required
to be ordered.

3.  I added a requirement (3.2.4) stating that each collection member must
appear in the ordering exactly once.  I added some text explaining the
implications of this for server behavior.

4.  I added a requirement (3.2.5) stating that orderings must not contain
resources that are not members of the collection, and again discussed the
implications of this for server behavior.

5.  I strengthened 3.2.6 to say that a server must return listings of
collection members in the order specified by the collection ordering.

6.  I added a requirement (3.1.15) stating that a referential member of a
collection is itself a resource.  I think this was already implied by the
requirement that referential members be able to carry their own properties,
but it needed to be made explicit.  As Jim noted, this has implications for
3.2.4.


At 11:02 AM 5/15/98 PDT, Jim Whitehead wrote:
>
>> At 04:58 PM 5/12/98 PDT, Jim Whitehead wrote:
>> >1) I have is the perception that there are really two different kinds of
>> >ordered collections.  The first are "live" collections where the
>> >ordering is maintained by the server, and any attempt by the client to
>place
>> >a resource at a specific location in a collection will (unless the client
>> >is lucky and places the resource where the server would put it anyway)
>> >not work. The second are "static" collections where the client maintains
>the
>> >ordering, and places resources in exact locations.  With "live"
>collections,
>> >the server maintains the semantics of the ordering, whereas with "static"
>> >collections, the client maintains the ordering. I think the ordered
>> >collections protocol draft needs to support both kinds.
>> >
>> >I think it would be useful to add some discussion of this distinction to
>> >Section 2.2 (which touches on it in the second paragraph), since these
>> >categories and labels will be useful in our discussion.
>>
>> I think that we have gradually been paring back the ordered collections
>> requirements to arrive at a point where the server is not required to
>> maintain orderings in any way -- so that orderings are always "dead,"
>> client-maintained.  Jim Davis has expressed his opposition to
>> server-maintained orderings.  In the more distant past, Yaron did, too,
>> although he may not care so much now that ordered collections are in a
>> separate specification.  So I'm a little reluctant to add back in a
>> requirement for "live" orderings.
>
>Ahh.  In this case, then, a note stating that the intent is to only support
>non-live ordering should be added.
>
>> That said, here's a related problem.  Based on the LA meeting, I took out
>> the requirements for orderings that contain only a subset of collections
>> members and for orderings that contain a collection member more than once.
>> The implication is that each collection member must be in an ordering
>> exactly once -- I should have added a requirement to this effect
>> to make it
>> explicit.  But once we say this, the server is required to do some work to
>> maintain the integrity of the ordering -- it must prevent clients from
>> adding members to orderings more than once and it must make sure that when
>> a member gets added to a collection, it gets added to the ordering
>> somewhere.  This is, by the WebDAV definition, "live," whether or not the
>> ordering is server-maintained (read-only).
>
>Well, this is certainly live in the sense that the server is performing some
>consistency checks before allowing a resource to be added to a collection,
>but it isn't live in the sense the server will be doing the actual ordering.
>So, I don't see a problem with the language in this case -- for any
>operation, the server is always allowed to perform some checks.
>
>However, this does raise a problem with repsect to referential members of
>collections, since we allow in 3.1.2 the same resource to be referenced
>multiple times int he same collection.  However, since we haven't said
>anything about having a local name for references, this implies to me that
>the same URI can appear in a collection mutiple times (once as an internal
>member, and then potentially multiple times as an reference).  An ordered
>collection then has to handle this situation.
>
>> >2) Requirement 3.2.3 should be strengthened so a server always
>> has to return
>> >the members of a collection in order.  I'm thinking of wording something
>> >along the lines of:
>> >
>> >When a client requests a listing of the members of a collection, this
>> >listing is returned in the order specified by the collection.
>>
>> Again, Jim Davis and Yaron have both opposed requiring a server to apply
>> the ordering to any list of collection members it returns.  Jim's view is
>> that it is just as easy for the client to retrieve the ordering and apply
>> it.  So that's how 3.2.3 got weakened to its current state.  Are there
>> others who think it should be strengthened again?
>
>Except that I think they were thinking the server would be performing some
>action like alphabetizing the listing before sending it out.  If the
>ordering is static (non-live), then returning the members of the collection
>in order seems reasonable to me.
>

Name:			Judith A. Slein
E-Mail:		slein@wrc.xerox.com
Internal Phone:  	8*222-5169
Fax:			(716) 422-2938
MailStop:		105-50C
Web Site:    http://www.nde.wrc.xerox.com/users/Slein/slein.htm

Received on Sunday, 17 May 1998 14:46:32 UTC