Jan wrote:
> > > I would also like to see sort as an option
> > > within CQL, not a separate
> > > service.

Rob wrote:
> Surely if there's any advantage to SOAP at all, then it's that it lets you
> easily parse requests by using existing XML libraries.
>
> Please can we not just dump everything in CQL, thereby losing the only
> advantage that SRW has over Z39.50 ?

I agree with Rob's sentiments, but sort of agree with Jan about
the niceness of merging SORT into CQL. I am actually thinking back
to the 'relevance' attribute which I think Rob supports to change
the order of a result set. That is, a ranking query is a form of
sorting. I can see benefit of ranking in a CQL query, so I can
also see the benefit of sorting in general in a CQL query.

But I don't have strong opinions here. I think scan should never
be merged into CQL. But a sort clause I can see benefit for as to
me it more relates to the query.


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.)

Or is it you can supply the query you want answered, plus a set of zero
or more queries with result set names. The set names are local to the
request. If the server did the queries recently and still has the
results around, it can use the cached result sets. Feels a bit ugly
though, especially with SRU where you are trying to put everything
into a URL argument.

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 the session id has time out, an error
is returned. If a followup query does not want to refer to previous
results, it ignores the session id the server returns. Maybe even
a request can include a 'preferred session lifetime' (if omitted,
sessions are never cached).


What I am trying to get at I guess is if we want to expose result sets
as Z39.50 result sets, then I think we should say 'record 3 is always
record 3' and return an error if the set has been lost. I would introduce
sessions as an implicit concept in this case so that result sets are
associated with a session.

Otherwise I see 'result sets' in SRU/SRW more as a caching concept.
No guarantee that the query won't be reissued so you might get a
different record. But as a cache, the server should not have to
have any memory of previous requests. So there is no concept of
referring to the result of a previous request (you just issue the
whole request again).


I personally don't mind either model. But I would be against a model
where there was no session id (or similar unique identification of
context) but you were allowed to refer to previous result sets.

Alan