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
