RE: Ordered Collections

Comments below.

> -----Original Message-----
> From: Judith Slein [mailto:slein@wrc.xerox.com]
> Sent: Friday, April 24, 1998 2:29 PM
> To: w3c-dist-auth@w3.org
> Subject: Ordered Collections
>
>
> Based on the minutes of the April 2 WebDAV meeting, it looks to me as if
> there is no consensus that ordered collections are needed.
> (Those who were present, correct me if this is the wrong interpretation.)

Hmm.  I wouldn't go this far -- my sense of the room was there is
substantial support for ordered collections.  Exactly what is meant by
"ordered" was the topic underlying most debate.

> Once these go away, requirement 3.2.3 becomes simply the requirement
> that a client be able to request that a response to a PROPFIND present
> the members order defined for that collection.

Agreed.

> So suppose we allow only a single ordering, and that it must contain each
> collection member exactly once.  Now it seems reasonable to say
> that we are getting nothing beyond what we could already get from
> a search with a sorting capability.  (I'm trying to reconstruct a
> train of thought from the minutes.  Correct me if I am wrong.)

Not exactly -- ordered collections can support arbitrary orderings (i.e.,
put "bar" first, "foo" second, "xxx" third, etc.) which is impossible to
accomplish with sorting.

> My view about this is that if we didn't have an ordering capability
> independent of search, we would in effect be implementing ordering as a
> property on each member of a collection.  I want to suggest that this is a
> bad implementation of ordering.  In particular, it violates requirement
> 3.2.9 that it be possible to modify an ordering efficiently.

This isn't the only possible ordering. As you point out in your last
paragraph, ordering information could be maintained in a property on the
collection.  Or, perhaps the repository for ordering state isn't even
available via a WebDAV abstraction (e.g., a database record), and is only
retrievable via a WebDAV property.

Short answer: I don't think this creates any efficiency concerns.

> Search with sort works well for ordering if the property that is the basis
> of the sort has a semantic life of its own independent of the ordering.
> That is, if we assign values to the property *not* based on solving the
> problem of getting the resource to sort to the right position,
> but based on
> some intrinsic feature of the resource.  So I assign a value to "Author"
> based on who created the resource, and it happens that I can sort
> alphabetically on author.  Or I can assign a value to "Difficulty-level"
> and then it's possible to sort from easy to difficult.

So this scenario sounds like a good use of DASL.

> But if I have 15 chapters of a book that I want to appear in a certain
> order, assigning a value to an "order" property is a bad way to
> get them to
> sort into that order.  I can't just assign 1 to the first
> chapter, 2 to the
> second, etc., unless I know that I will never want to insert a new chapter
> in the middle of the book.  I can leave gaps between the values to allow
> for some number of insertions, but those might get used up.  In short,
> maintenance of an ordering implemented in this way is extremely
> inefficient.

This sounds like a good use of DAV ordered collections.

> So my view is that a better implementation of ordering is the one many
> people have had in mind all along:  as a property on the collection that
> lists its members in the desired order.

Well, I tihnk this will need to be explored in the protocol document for
ordered collections, but it strikes me that this might be a good way to
quickly retrieve the ordering of a collection. On the other hand, if
PROPFIND of Depth 1 can also retrieve the ordering of a collection, perhaps
we don't want two ways of getting at the same information.

- Jim

Received on Friday, 8 May 1998 19:18:51 UTC