Date:         Wed, 10 Jul 2002 16:53:07 +0200
Reply-To:     "Z39.50 Next-Generation Initiative" <[log in to unmask]>
Sender:       "Z39.50 Next-Generation Initiative" <[log in to unmask]>
From:         Theo van Veen <[log in to unmask]>
Subject:      Betr.: Re: sort parameter
Comments: To: [log in to unmask]
Content-Type: text/plain; charset=US-ASCII

My approach would be: take the time to see how different implementors handle sort, but lets agree that there is at least a parameter available (lets call it "sortid"), the use of which is at the moment defined locally. As Ralph pointed out already these specs do not have to be static and may be refined later.

Theo


>>> [log in to unmask] 10-07-02 16:08 >>>
I'll admit I don't particularly like any of the approaches suggested
(including mine) but I suppose we'll select one of these later this week (or
maybe someone will come up with an inspired approach that nobody's thought of
so far).  --Ray

Mike Taylor wrote:

> > Date: Tue, 9 Jul 2002 16:36:31 -0400
> > From: Ray Denenberg <[log in to unmask]>
> >
> > > > I thought the solution we agreed upon was that this and other
> > > > features would be implicit in the sort key name.
>
> ... I don't remember agreeing any such thing.
>
> > > Yes, but under duress :) Or more accurately, that it works if the
> > > key only has one thing tacked on the end, but will we end up with
> > > monsters like:
> > >
> > > <sortkey xsi:type="xsd:string">
> > > AuthorLastNameCommaFirstNameAscendingCaseSensitiveMissingValueOmit
> > > </sortkey>
>
> Yes indeed, this is too awful to contemplate.
>
> > No! "implicit" not "explicit".
> >
> > We haven't really said what these keys will look like, but one
> > possibility is that your server would support keys: 'author1'
> > defined as: Author: " Last name, first name" Ascending, Case
> > Sensitive, Missing Value Omit\ 'author2': " Last name, first name"
> > Descending.....
>
> That's even worse!  There's no rational way for a client to know what
> to use.
>
> > And that these are either well-known or discoverable via explain.
>
> How?  Why make new problems for Explain to solve when we could just as
> easily just define this stuff properly?  If we're going to have SRW
> provide anything like "serious IR", we must surely avoid going down
> this blind alley of mutually incompatible random semantics.  ("On
> _our_ server, author42 means sort by author's _surname_ descending and
> case-insensitively.")
>
> Please, please, can we _either_ define a proper hunk of XML that says
> what we mean, simply and directly, like this:
>
>         <sortSpec>
>           <sortKey index="author" direction="descending" case="ignore"/>
>           <sortKey index="title"/ direction="ascending">
>           <sortKey index="subject"/ direction="descending" case="respect">
>         </sortSpec>
>
> or define a simple, human-writable Common Sort Language, like this:
>
>         -author/i +title -subject/r
>
> My personal preference is mildly in favour of the latter, but I will
> be happy with either of these outcomes.  What I _don't_ want to see is
> a hybrid like this:
>
>         <sortSpec>
>           <sortKey index="-author/i"/>
>           <sortKey index="+title"/>
>           <sortKey index="-subject/r">
>         </sortSpec>
>
>  _/|_    ___________________________________________________Iorg.uk
> )_v__/\  "You cannot really appreciate Dilbert unless you've read it
>          in the original Klingon." -- Klingon Programming Mantra