On Fri, Jun 21, 2002 at 09:43:50AM -0400, Ray Denenberg wrote:
> A Sort parameter, might look something like this:
>
> -----------------
> <sort>
> <sortKey direction="ascending"> <index>bathTitleWord</index></sortKey>
> <sortKey direction="ascending">
> <elementPath schema= "schema identifier">
> <element> element1</element>
> <element> element2</element>
> ....
> </elementPath>
> </sortKey>
> <sortKey direction="ascending"> <sortKeyName> title <sortKeyName></sortKey>
> </sort>
> ---------------------
>
> That gives three options: index (Rob), element path (Ralph), or sort key name
> (Alan).
>
> Do we need all three or can we agree on one?
>
> --Ray
I think having 3 would be bad - overly complex. I think we all want to
try and keep it simple.
If you want sorting in SRU, doesn't this mean the sort specifications
should be able to be reduced to a simple list of strings? (XML encoding
parameters I think is ugly).
Using index names I don't think is enough. There are lots of parameters
that need to be passed to a Z39.50 sort request.
Using element paths I dislike because I don't know how to turn it into
a Z39.50 sort request. It also relies on the XML structure of the
returned XML. What if I use an XSLT etc stylesheet to tranform the
database stored XML into the returned XML (for supporting different
schemas). In order to support the sorting as specified, I need to
map the element names in the returne XML structure back to the database
stored XML structure, then work out how to turn that into a Z39.50
sort request which does not have element paths (if I am understanding
the request).
My final proposal (case 3) is not to have a direction attribute, but
rather have it implied by the sort key name. That is, a single name
identifies the complete set of values to plug into a Z39.50 sort request.
This works well with SRU too.
Here are all the Z39.50 sort parameters that are in the spec:
SortKey being one of
- sort field (a string where its up to the server what it means)
- element spec
- attribute list
sortRelation (ascending, descending, ascByFrequency, descByFreq)
caseSensitivity
missing value action (abort, null, missingValueData = XXXX)
I hesitate to say 'lets support asending/descending, but not case
sensitivity or missing value action', only because someone may come
along later and want it. But I also dislike putting too much complexity
in SRU/SRW. Hence my suggestion of a simple sort key name where the
gateway can turn it into whatever sort request it wants to. As soon
as you say 'ascending/descending should be a paramter because its
different', why not case sentitivity too? or missing value action?
But I am happy to go along with whatever people decide - as long as
there is an algorithm for converting the SRU/SRW request into a
Z39.50 sort request.
Alan
|