Search

RETS Change Proposal 15: Allow Ordering of DMQL Query Responses
Author: Pete Clarno
Organization: Software & Vine, Inc.
Telephone: (805)227-1545
Address: 825 Riverside, Suite 13, Paso Robles, CA
Email: pete@swvine.com
Status: Proposal
Date: 07/24/2002
Proposal Version: 1.5
1. Synopsis
This proposal adds a new order by argument to the Search Transaction, a new sortable field to content metadata and a new error code to query responses.
2. Rationale
Unlike the rich client model where bulk data is replicated on the client in a batch manner and specific queries are processed locally on demand, a thin client model assumes that a RETS server acts as a central data repository and delivers smaller amounts of data from more specific queries, on demand, durring interactive sessions. While current DMQL syntax offers limit and offset parameters that would help reduce the dataset returned, it does not offer a sorting capability. This negates much of the usefulness of the limit and offset functionality, since results may be returned in any arbitrary order. By adding an order by parameter similar to that used in SQL, the client is assured of being returned the most meaningful data (according to client criteria) first. This substantially reduces the amount of data that must be served up, transmitted and consumed, thus substantially improving the user experience in a thin client environment.
3. Proposal
3.1 Add a new "order by" clause to the Optional Request Arguments of Section 7

A new subsection entitled "Order By" should be added to the Optional Request Arguments of Section 7.4. The OrderBy argument requests the server to provide the results of the query in a specified sequence.

Order By ::= (field [Asc|Desc]) *(,field [Asc|Desc])

This parameter is used to determine which field(s) are to be used to determine the sequencing of results returned by the query. The field(s) specified MUST be a system name or standard name field (as determined by the StandardNames flag) for which the Sortable Field in the Metadata Content Table is set to true. (See proposal 3.2 below for additional information on the Sortable Field.)

An optional directional indicator MAY be used to determine whether the list is sorted in Ascending (Asc) or Descending (Desc) order. If omitted, ascending order is assumed.

If the Server indicates that a field is Sortable in the metadata content, it MUST honor the client request for sorting by a single field. However, if the client requests multiple sorts columns which may create an undo burden on the server, the Server MAY return an error code or simply sort on the first field requested. If the field requested is not a Sortable field, the Server MUST return an error code. (See proposal 3.3 for suggested changes to error codes.)

: The collation sequence is implementation specific and not controllable by the client.

Example:  Order By=ListPrice Desc

Instructs the server to return the result set with the highest priced property at top of the list.

3.2 Add a new "sortable" value to the Table metadata
Field NameContent TypeDescriptions
SortableBooleanA truth-value which indicates that the field is sortable

3.3 Add two new Reply Codes to Section 7.8
Reply CodeMeaning
TBDThe requested Order By field is not a sortable value
TBDThe sort requested is too complex to be honored

4. Development Impact
The impact on Server developers varies from modest (adding a value to the table metadata) to rather extensive (developing an efficient sort mechanism for their server) depending upon their level of support for the proposed change. At minimum server may elect to simply revise the metadata to indicate that no fields are sortable, thus indicating that the OrderBy clause is not supported. Client developers wishing to take advantage of the sort capabilities would need to revise their program accordingly.
5. Compatibility
This feature is envisioned as a dot release enhancement to the DTD. Servers that do not support this feature would return a metadata version tag indicative of that fact. Clients wishing to support multiple metadata versions would need to adapt to this information.
6. Proof/Need of Concept Examples
None.