I agree with Alan that the problem with tagpath sorting is that there is no
classic equivalent.

I'll support his alternative proposal.

Ralph

> -----Original Message-----
> From: Alan Kent [mailto:[log in to unmask]]
> Sent: Sunday, June 23, 2002 9:01 PM
> To: [log in to unmask]
> Subject: Re: sort parameter
>
>
> 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
>