Re: Advanced collections and ordering

I substantially agree with JimD. There are many clients accessing each
WebDAV server, each with their own views and sorting requirements. Having
the server support a specific collection sorting might meet the needs of
some of these clients, but certainly not all. The same data will need to be
sorted many different ways. The best way to do this is to let the
interested parties (the clients, perhaps through XSL) do their own sorting
to meet their needs and have the servers just serve up the data.

However, there are some instances when the semantics of data do rely on
sorting and servers would be expected to maintain the ordering in order to
maintain the semantics. This would usually be the domain of resource
contents not properties though. I believe that unless we are willing to 1)
support multiple, client specified orderings, and 2) provide an
extensibility mechanism to implement the desired collation sequence (a
comparison operator), then ordered collections will not be particularly
useful, will not be widely implemented, and should be deferred.





"Jim Davis" <jdavis@coursenet.com> on 04/13/99 01:24:36 PM

To:   w3c-dist-auth@w3.org
cc:    (bcc: Jim Amsden/Raleigh/IBM)

Subject:  Re: Advanced collections and ordering




At 02:22 PM 4/13/99 +0000, John Stracke wrote:
>Jim Davis wrote:
>
>> In my opinion, a server that wished to provide three distinct sorted
views
>> on one underlying collection would best do it by advertising three
distinct
>> collections, each supporting exactly one sort,e g.
>> ...
>... this approach requires the server to know that it's being a message
>forum; it has to include code to render these ordered collections.

We are rapidly falling down a slippery slope along the following trajectory

1) client-side sorting

2) server-side sorting (server chooses)

3) server-side sorting (client chooses)

ACR provides #1 now.  Someone (I forget who) suggested that for those
servers that maintain a sort anyway, they may as well be able to advertise
that sort.  Thus #2.  The example offered to justify this was a mail
server.   I tried to show why this example was not very useful.    Now you
seem to be asking for the ability for the client to tell the server
 a) sort this collection using this ordering
 b) maintain this sort in the future

I object to this

1) It's an unreasonable burden on the server.  it's just as easy for the
client to sort as for he server to sort, and there are more clients than
servers.

2) It leads to a further slippery slope.  If the server is expected to sort
based on arbitrary sort identifiers, than why not ask it sort based on
arbitrary DASL expressions, or for that matter arbitrary download Java
expressions?

3) There's no demonstrated need.  it's certainly not sufficient to
construct a mail server.

>Assuming the human speaks English.  Anyway, I wasn't intending that the
sorting
>mechanism be exposed to the user; you'd click on a sort criterion and see
your
>messages get reordered, much as in an ordinary mailer.

This will certainly be done client side for best speed.  That's how modern
day browsers do it (e.g. Eudora).  You would not want to wait for a round
trip.

In summary, I  still see no need for a collection that is sorted server
side (what you might call a "live sort") to advertise its sorting, nor a
need for the client to tell the server the live sort to be used.

> (A nice DASL extension might be a way for the client to tell the
>server, "I
>expect to make this query frequently; you might want to keep an index for
it.")

That's an interesting idea but I hope you won't be offended if I ask to put
it off until the base level of DASL is done.  As you said, it's a nice
*extension*.
please reply to jrd3@alum.mit.edu, despite the Reply-To address in the
header.

Received on Tuesday, 13 April 1999 15:58:18 UTC