I have no problem with saying that a result set name must always be returned
and must be immutable (that's a Java word!) It doesn't need to be
persistent and the server will give a hint as to how long it will remain. I
think we must be compliant with the current z39.50 model which says that a
result set is a surrogate for an ordered set of records.
Ralph
-----Original Message-----
From: Mike Taylor [mailto:[log in to unmask]]
Sent: Thursday, June 13, 2002 12:36 PM
To: [log in to unmask]
Subject: Re: result set model for srw
> Date: Thu, 13 Jun 2002 11:08:21 -0400
> From: Ray Denenberg <[log in to unmask]>
>
> > Is it SRW/SRU give access to previous Z39.50 result sets? (Which
> > may be timed out before you get to them.)
>
> I suggest we distinguish based on whether or not a result set name
> is included in the response. Remember that the server may or may not
> supply a result set name; we decided this a long time ago, though it
> was a contentious topic. Some felt that the cql string itself is
> sufficient as a result set name, others dissagreed. However we
> never did completely articulate any different behavior or semantics
> between the two cases (that I can recall), that is, when a response
> includes a result set name and when it does not.
>
> I suggest that when a response does not include a result set name
> then the client should not assume that there is an ordered, stable
> result set. The server may use cached results, treat the query
> string as a result set name, or re-execute the query, as it sees
> fit, transparent to the client.
>
> When the response includes a result set name then perhaps it is
> reasonable to impose more stringent rules, i.e. the client may
> assume an ordered set, thus in a subsequent request, if the cql
> string is just a result set name then the request is to be construed
> as a present against that result set, and the query should not be
> re-executed (unless the server guarantees identical results). If the
> result set isn't around, then the server returns an error.
>
> And further, if we include some kind of sort paramer, at the SRW
> level (not within cql) then if a result set name is supplied in the
> request it refers to the sorted result set. If no result set name is
> included in the request, then if the same cql string is supplied in
> a subsequent request, the server might re-execute the query and the
> results might be in a different order (unless the same sort
> parameter is also included).
I've quoted this suggestion in its entirety so I have context in which
to ask this question: who is looking forward to explaining all this to
the ZIG, the W3C or anyone else? Who's going to enjoy writing
tutorials for this rat's nest of logic?
Heuristics, implied semantics, wild conjecture ... In the name of
simplicity, we have allowed all this to get very complex.
If we want to do serious IR, then we need result sets. So let's have
them in the protocol properly and have done. If we prize simplicity
over power, then let's NOT have them. But please, not this
wishy-washy, in-between, will-he won't-he compromise.
Revelation 3:16 has words to offer on this subject :-)
_/|_ _______________________________________________________________
/o ) \/ Mike Taylor <[log in to unmask]> www.miketaylor.org.uk
)_v__/\ "What is this talk of 'release'? Klingons do not make
software 'releases'. Our software 'escapes,' leaving a
bloody trail of designers and quality assurance people in
its wake." -- Klingon Programming Mantra
