Although I posted a different proposal, I like the simplicity of Alan's
proposal. As long as there is no error message returned when the
server cannot do the requested sort I also support that proposal.

Theo

On 24 Jun 02, at 8:04, LeVan,Ralph wrote:

> 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
> >