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.

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.

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

OK.

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

OK.

- Jim

Received on Friday, 15 May 1998 14:02:13 UTC