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

Re: Sort criteria in Search Request

From: Ray Denenberg <rden@loc.gov>
Date: Fri, 14 Sep 2001 17:10:19 -0400
Message-ID: <3BA2723B.7E310FD4@rs8.loc.gov>
To: ZIG <www-zig@w3.org>
Following-up on this, I've written up a proposed commentary,
and it's on the meeting agenda.

My point is to illustrate how easy this is (even though you have to support
encapsulation). Or let me put it this way: a number of people said "encapsulation is
too hard, let's just come up with an agreement to put a sort pdu in otherInfo".
That's all the proposal does basically, is put a sort pdu in Otherinfo (and set an
option bit).

Those of you who expressed doubt, please look at the proposal: what could be
easier?  Is it really better, just to avoid negotiating encapsulation, to come up
with an out-of-band agreement that does essentially the same thing?

If you still object, because this requires you to set the option bit claiming
support for encapsulation (so you think you're entering into a contract requiring
you to support all manner of encapsulations) we could go a step further, define a
new option bit that qualifies the encapsulation option bit restricting it to "sort
in Search".  I'm willing, but is it really necessary?


Ray Denenberg wrote:

> I'm joining this discussion late, as I  was away all last week......
> Sebastian Hammer wrote:
> > ..... 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, ....
> I'm disturbed by the suggestion to use anything other than encapsulation. It
> calls into question the entire ZIG/Maintenance Agency relationship and process.
> Significant effort went into the encapsulation specification. Nevertheless, if
> it's too heavyweight and clumsy then let's get rid of it, rather than continue
> to ignore it.
> All of the clarifications, amendments, etc, are being rolled into a consolidated
> draft-for-ballot (that will be ready for review before the ZIG meeting, and will
> be on the agenda for discussion at the meeting) of a proposed new
> maintenance-revision of Z39.50.   The Encapsulation amendment will be part of
> this revision. Those of you who do not see encapsulation as appropriate for
> sort-lookahead should be either be prepared to explain why encapsulation should
> remain part of the revision if it cannot be used with sort, or should be
> prepared to argue that Encapsulation should be removed.
> Now, assuming that encapsulation is potentially useful, it's important to
> remember that it was aimed directly at the kind of functionality were
> discussing. More specifically, the aim of encapsulation is optimization and
> there are three types listed in the spec (see
> http://lcweb.loc.gov/z3950/agency/amend/encapsulation.html) one of which is
> "lookahead" characterized by a "Sort encapsulated within a Search, allowing the
> server to optimize the search by knowing, a priori, the desired sort order".
> Here is a suggestion: we could come up with an implementor agreement that
> described how to use encapsulation explicitly for this purpose. It's just a
> matter of sticking a sort pdu into the otherInfo parameter of a search. The
> overhead of using encapsulation is negligible. We could even define an option
> bit for this (thus you could negotiate the use of encapsulation exclusively for
> sort-lookahead).  And we could possibly approve this at the October meeting and
> get it into the revision.
> Is this a good idea?
> --
> Ray Denenberg
> Library of Congress
> rden@loc.gov
> 202-707-5795

Ray Denenberg
Library of Congress
Received on Friday, 14 September 2001 17:10:09 UTC

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