sorted response inefficient for UIs that need indendation.

Suppose I want to search a repository such that results are sorted first by
name, then by date, and I want the UI to display the results in a tree,
with the first level of indenting showing aggregation by name, and the
second level by date, e.g.

 Borenstein, Kate
    My Life in the Bush of Ghosts (Dec 1992)
    Gender Outlaw (Mar 1995)
 Carter, James
    Politics for Dummies (1984)
    Modern Carpentry (1997)

Reasonable thing to desire, yes?

One problem is that while the DASL can indeed sort the responses in this
order, the response list is flat, so that the UI client must compare each
record with the previous one to determine how much indentation to use.  If
the record has the same author, then it must differ in date, so it gets an
extra level of depth.    This means

 1) the client must duplicate the comparisons that the server had to do,
which wastes effort

 2) In order to do this, the client must select all the properties that
were used in the sortby, so that it has sufficient information to do the
comparison.  This wastes bandwidth.

One possible solution is to define a new psuedo property, let's call it
dav:sortindex, which is the index of the first order element in the sortby
where the resource differed from the previous one.  This property would be
selectable but could not be used in a where or sortby clause.  This is
sufficient to allow the UI described above.

Should we add this?  Well, it might be expensive to implement, if for
example, the server used a SQL engine to do the sorting.   If the server
itself does not know the value (the underlying RDBMS knows, but does not
tell in the SQL reply) then it would require the server to compute it.
Such servers should just not support dav:sortindex as a selectable property.  

Adding dav:sortindex would allow servers that CAN compute it cheaply to
return it, saving work, but would not help clients of servers that don't
support it.  Is there even one server that could plausibly compute it?  If
so, it's probably worth adding.  If not, let's skip it.  We can always add
it later.

Received on Friday, 19 June 1998 17:31:35 UTC