W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 1998

Ordered Collections

From: Judith Slein <slein@wrc.xerox.com>
Date: Fri, 24 Apr 1998 14:28:49 PDT
Message-Id: <3.0.3.32.19980424172849.00a54c40@pop-server.wrc.xerox.com>
To: w3c-dist-auth@w3.org
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.)

A number of requirements (3.2.6 - 3.2.8) for complicated sorts of orderings
will probably be dropped because they are equivalent to creating multiple
collections, each with a single, simple ordering.  These were the
requirements for multiple orderings on a single collections, for orderings
that include a single member multiple times, and orderings that include
only a subset of collection members.  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.

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

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.

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.  

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.

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.

--Judy

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 Friday, 24 April 1998 18:52:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:47 GMT