Skip
repetitive navigational links
L-Soft  -  Home of  the  LISTSERV  mailing list  manager LISTSERV(R) 14.5
Skip repetitive navigational links
Previous messageNext messagePrevious in topicNext in topicPrevious by same authorNext by same authorPrevious page (July 2002)Back to main ZNG pageJoin or leave ZNGReplyPost a new messageSearchProportional fontNon-proportional fontLog in
Date:         Wed, 10 Jul 2002 13:34:27 +0100
Reply-To:     "Z39.50 Next-Generation Initiative" <[log in to unmask]>
Sender:       "Z39.50 Next-Generation Initiative" <[log in to unmask]>
From:         Mike Taylor <[log in to unmask]>
Subject:      Re: sort parameter
Comments: To: [log in to unmask]
In-Reply-To:  <[log in to unmask]> (message from Ray Denenberg on Tue, 9
              Jul 2002 16:36:31 -0400)

> 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> _/|_ _______________________________________________________________ /o ) \/ Mike Taylor <[log in to unmask]> www.miketaylor.org.uk )_v__/\ "You cannot really appreciate Dilbert unless you've read it in the original Klingon." -- Klingon Programming Mantra


Back to: Top of message | Previous page | Main ZNG page

LISTSERV.LOC.GOV CataList email list search Powered by LISTSERV email list manager