On Fri, Jun 21, 2002 at 09:36:37AM +0200, Janifer Gatenby wrote:
> With sort we need to be able to specify in particular date ascending and
> date descending.  They don't fit neatly into CQL index; some servers may
> support them for sort but not for retrieval or only for retrieval as a
> limiter.
>
> Janifer

The Z39.50 sort specification, as you point out, has a number of
options. There is ascending/descending, but there is also missing
value actions, case sensitivity, ascending/descending by frequency
and other things too.

I was initially going to suggest making ascending/descending a separate
argument. But with all the other options, how far do we go? Is it
reasonable/good/bad to go to the extreme of saying there are named
sort specifications, where the gateway is responsible for the complete
mapping of that name onto the full Z39.50 SortKeySpec? This would
mean you need to define two names 'dateAscending' and 'dateDescending'
(for example).

Note: There are an array of SortKeySpec's in the protocol by the way
for secondary keys etc. This means if ASC/DESC was separated from
the sort key name, you would need an array of structs if you want
to support sorting on multiple keys - which would not work well with
SRU. If you stick to a set of names (where the name implied the order)
then its a simple repeating parameter - which can be done in SRU.


I don't have any preference here, just trying to flesh out possibilities.

Alan