W3C home > Mailing lists > Public > www-zig@w3.org > August 2001

Re: Sort criteria in Search Request

From: Sebastian Hammer <quinn@indexdata.dk>
Date: Sun, 26 Aug 2001 23:33:09 +0200
Message-Id: <>
To: Robert Sanderson <azaroth@liverpool.ac.uk>, Ian Ibbotson <ian.ibbotson@k-int.com>
Cc: <www-zig@w3c.org>
At 12:28 25-08-01 +0100, Robert Sanderson wrote:

>You could just use ZNG ;)
>But less flippantly, if you're going to include sort in search, why not
>also include init and present? At which point, why not get rid of state
>and resultsets? At which point, why not just use <any other system here>?

My response would be, "because Z39.50 is there, it works, we're building 
applications with it". Personally, I'd rather see an evolutionary 
improvement which maintains backwards compatibility (and allows us to roll 
over deployed implementations gradually), than a series of revolutionary 
and possibly disruptive bounces.

In one of our Z39.50-based databases, we've "cheated" and embedded sort 
criteria in the query by OR'ing on extra terms with a different attribute 
type used to indicate sorting. We did this to allow control of the facility 
from v2-based clients, and it's not an approach I would recommend. I WOULD 
like to see a method for embedding sort in the search (present is already 
in there there, apart from a few annoying details). Many applications 
require explicit sorting, and I feel that concatenation is too heavyweight 
and clumsy a mechanism for the job.

I think my preferred mechanism would be an extension to the search PDU, 
negotiated by an option bit. Runner-up would be an AdditionalSearchInfo, as 
Rob Bull suggests.

Sebastian Hammer        <quinn@indexdata.dk>            Index Data ApS
Ph.: +45 3341 0100    <http://www.indexdata.dk>    Fax: +45 3341 0101
Received on Sunday, 26 August 2001 17:32:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:26:03 UTC