Date:         Thu, 13 Jun 2002 11:08:21 -0400
Reply-To:     "Z39.50 Next-Generation Initiative" <[log in to unmask]>
Sender:       "Z39.50 Next-Generation Initiative" <[log in to unmask]>
From:         Ray Denenberg <[log in to unmask]>
Organization: Library Of Congress
Subject:      Re: result set model for srw
Comments: To: "Z39.50 Next-Generation Initiative" <[log in to unmask]>
Content-Type: text/plain; charset=us-ascii

Alan Kent wrote:

> I agree with Rob's sentiments, but sort of agree with Jan about
> the niceness of merging SORT into CQL.

I need to ask you the same question I asked Jan yesterday: do you really mean in
CQL or would a separate SRW parameter be sufficient?


>
> I guess it also depends on the abstract result set model that SRW/SRU
> goes with. I would like to first agree on what the correct abstract
> model is before working out mechanics.
>
> 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).

> Or is it you can supply the query you want answered, plus a set of zero
> or more queries with result set names.

I didn't follow this.


> I can see the benefit in being stateless (SOAP and URLs are sort of
> meant to be stateless after all). If state is important, then I think
> it needs to be explicit. For example, allow a response to include
> a session id (with a time to live value). Following requests are allowed
> to include that session id.

If we have (persistent) result set names, do we still need session ids?

--Ray