RE: Ordered Collections

Thanks for your comments, Jim. I've made most of your suggested changes,
but I'm hesitating about a few of them.

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.

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

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

>
>Minor points follow:
>
>>      2.1  Referential Members
>>
>>         Referential members make it possible for many collections, on the
>>         same or different servers, to share the same resource.  Because
>>         the collections share the resource by referencing it, only one
>>         physical copy of the resource need exist, and any changes made in
>>         the resource are visible from all the collections that reference
>>         it.
>
>
>Instead of "physical copy", I prefer the term "authoritative location" since
>it is technically possible to have the same physical data chunk accessible
>at multiple locations (e.g., a file which can be accessed via FTP and HTTP),
>so by referring to one of these location with a referential member, the
>referential member doesn't really point to the physical data chunk, it
>points to one location at which that physical data chunk can be accessed.
>
I've stayed with "physical copy" because I think it's clearer and it's
really the point.  Whether the referential member points to its target at
the FTP location or the HTTP location, the important thing is that we
didn't have to make a physical copy of the resource inside the collection
in order to get access to it through the collection.

>
>>         So for example, two users from different organizations, using
>>         different authoring tools, are working together to create a
>>         collection.  One of the tools uses a property on the collection
>>         called "Order" to store an ordering of the collection.  The other
>>         tool uses a property on the member called "SequenceNumber".  If
>>         each user adds some members to the collection, there will be no
>>         reliable ordering.
>
>At the end of the last sentence, add "across tools."
>

I kept this as it was because it's really true that there will be no
reliable ordering. Period.  It's not that one tool could get you access to
a reliable ordering, but the other could not.  Once you have modified an
ordering using each of the tools, neither ordering is reliable any more.


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 Thursday, 14 May 1998 11:46:05 UTC