LISTSERV mailing list manager LISTSERV 16.0

Help for ZNG Archives


ZNG Archives

ZNG Archives


[email protected]


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

ZNG Home

ZNG Home

ZNG  July 2002

ZNG July 2002

Subject:

Betr.: Re: sort parameter

From:

Theo van Veen <[log in to unmask]>

Reply-To:

Z39.50 Next-Generation Initiative

Date:

Wed, 10 Jul 2002 16:53:07 +0200

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (78 lines)

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

Top of Message | Previous Page | Permalink

Advanced Options


Options

Error during command authentication.

Error - unable to initiate communication with LISTSERV (errno=111). The server is probably not started.

Log In

Log In

Get Password

Get Password


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

ATOM RSS1 RSS2



LISTSERV.LOC.GOV

CataList Email List Search Powered by the LISTSERV Email List Manager