- From: Sebastian Hammer <quinn@indexdata.dk>
- Date: Sun, 26 Aug 2001 23:33:09 +0200
- 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 -- 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