proposal for sortby

The defintition for sortby (which I wrote) in the current protocol
draft is too weak.  It lacks means of specifying the direction of
sorting (up or down) and expressing the choice of sorting sequence
(which differs among natural languages).  Hence the following proposed
replacment:

In section 7.3

modify sortby to read

<!ELEMENT sortby  (order+) >

and add

<!ELEMENT order (prop, (ascending | descending)?, casesensitive?, language?)
<!ELEMENT ascending EMPTY>
<!ELEMENT descending EMPTY>
<!ELEMENT casesensitive #(PCDATA)>  ; T or F
<!ELEMENT language (#PC-DATA) ; as in RFC-1766

modfy the example

    <d:sortby>
        <d:order>
            <d:prop><d:getcontentlength/><d:prop>
            <d:ascending/>
        </d:order>
    </d:sortby>

Modify section 7.7

7.7 DAV:sortby 

The DAV:sortby element specifies the ordering of the result set.  It
contains one or more dav:order elements, each of which which specifies
a comparison between two items in the result set. Informally, a
comparison specifies a test that determines whether one resource
appears before another in the result set.  Comparisons are applied in
the order they occur in the sortby element, earlier comparisons being
more significant.  

The comparisons defined here use only a single property from each
resource, compared using either the dav:lt operator (ascending) or
dav:gt operator (descending).  If neither direction is specified, the
default is dav:ascending.

[Note that we use new elements dav:ascending and dav:descending rather
than just using dav:lt and dav:gt because the syntax of the latter
does not allow them to be used as empty tags.]

In some cases, a comparison may yield an undefined result, e.g. when
the property being compared is not defined on both resources, or where
it has incommensurable values.  In such cases the server MAY use any
order it likes.

7.7.1 Comparing natural language strings.

For those properties that are natural language strings, the comparison
may specify the natural language whose sort order is to be used.  The
comparison may also specify whether or not case is significant. 

Most languages define sorting orders for strings expressed in their
alphabet.  DASL provides means to request a single national sort order
for a given comparison.  A server that does not understand the
requested language order requested MUST reject the request.  DASL does
not define the behavior of a comparison that uses characters outside
those of the requested national language (e.g. the comparison of
katakana data in french is undefined.  A server MAY use any ordering
it wishes for such comparisons.

DASL does not define the sorting orders for any natural language. 

[Note that these same considerations apply to string comparisons in
the where clause.  Note also that the DTD here uses an element
casesensitive rather than an attribute casesensitive, because elements
are easier to deal with than XML attributes.]

7.7.2 Example

This sort orders first by last name of the author, using dutch
language conventions for comparison, so that, e.g. documents by "van
Bree" appear before those by "Korteweg", and then by size, in descending
order, so that the briefest works of "Langepratten" appear first.

<d:sortby>
  <d:order>
    <d:prop><r:lastname/></d:prop>
    <d:ascending/>
    <d:language>nl</d:language>
  </d:order>
  <d:order>
    <d:prop><d:getcontentlength/></d:prop>
    <d:descending/>
  </d:order>
</d:sortby>


Add to references

[RFC1766] H. Alvestrand, "Tags for the Identification of Languages",
RFC 1766 March 1995,

Received on Sunday, 14 June 1998 16:06:22 UTC