- From: <jamsden@us.ibm.com>
- Date: Tue, 13 Apr 1999 15:54:11 -0400
- To: w3c-dist-auth@w3.org
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