W3C home > Mailing lists > Public > www-webdav-dasl@w3.org > April to June 1998

Re: sorted response inefficient for UIs that need indendation.

From: Jim Davis <jdavis@parc.xerox.com>
Date: Sat, 20 Jun 1998 11:17:56 PDT
Message-Id: <>
To: <www-webdav-dasl@w3.org>
At 09:42 AM 6/20/98 PDT, Mark D. Anderson wrote:
>Your proposal only deals with a primary sort. What if
>I want to retrieve the author, the document type (book
>vs. article), and the title, and have the results
>indented 2-deep?

Unless I am mistaken, my proposal works for an N-level sort.  Perhaps I
explained it poorly?  The proposal calls for a property whose value is the
index of the first sorting where the records differed.  Therefore they must
be the same on all previous sorts, so the indentation depth is just this

Or am I confused?

>It strikes me that this is actually a directive for
>how results should be returned, not a modification of
>the query, and the two notions should be kept separate.

You are correct, and they *are* separate.  The proposed property appears in
the select clause, not the where clause.  The where clause specifies the
criteria that must be true of each record returned, the select clause
specifies the information to be returned of each such record.  They are
distinct.  One may SELECT (ask to be returned) e.g. the author, title, and
date of all resources that are (WHERE) the length is greater than 259.

>The client could specify that it accepts/prefers results
>returned with "encoded-repeaters". The server returns
>with results in that form, with a header indicating that
>they are encoded in that fashion and indicating what
>the special value is that is used to note a repeated
>value ....Basically this amounts to support for a "ditto" value.

I don't understand this at all.  If you want to propose it, I think you
should provide an example.  On the other hand, if the source of your
disagreement was my unclear explanation before, perhaps now you'll withdraw
your objection?
Received on Saturday, 20 June 1998 14:18:47 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:22:39 UTC