If we ONLY return a resultsetname when there is actually set of records and we add recordnumbers to these returned records and we do not allow the resultset being part of a query, than most of the problems below can be solved more easily.
1) Is doen not make sense that a server returns a resultsetname if that only refers to the query and not to a set of records.
2) When we add record numbers it makes references to records unambiguous
3) When the resultset cannot be part of the query the client always have to make a new query preventing problems with interoperability because this will always work and for resultsets it is not a priori sure that they are supported.
A sort parameter does not have to be part of CQL (lets keep CQL as simple as posiible). The sort parameter could be a list of comma-separated fields that should be used for searching or a reserved word for different types of relevance. If sorting is not supported the server returns an unsorted list with a diagnostic leaving it up to the client to do the sorting itself.
Theo
>>> [log in to unmask] 12-06-02 18:54 >>>
The status discussion leads me to conclude that we
need to formalize, at least to some degree, the
srw result set model --not anything as elaborate
as in real Z39.50, but consider for example this
scenario:
A query results in 5 records; the server supplies
all 5 in the response. The client then requests
result set record 5 (perhaps in a different record
schema). All three of these are possible:
1. the server has created a real result set, and
returns the expected record.
2. the server re-executes the query, an identical
result set is created and the client gets the
expected record.
3. the server re-executes the query, but this time
the result set is different so the client gets a
record other than the one expected. (This case
isn't really valid in real Z39.50.)
To what extent do we want to model the capability
for a client to request a specific result set
record that it has retrieved before and wants to
retrieve again? Is the stability of the result
set something that can be reflected in the "result
set status"? (I know we have a time-to-live
parameter. Is that sufficient?)
This is related to the surrogate diagnostics
discussion: if a response has surrogate
diagnostics, first, are they positional, and if
so, would they be in the same place each time?
Could the surrogate diagnostics occur in the list
of diagnostics as opposed to positionally, and the
server just return the good records?
Another issue: suppose a query doesn't complete.
Do we automatically assume no results, or can
there be a possibility of partial results....
Matthew Dovey wrote:
> Also I would think that a failure response in
> one of these statuses
> would effectively negate the other two.
>
> E.g. a failure of the search would also imply
> failure of the resultset
> and present, failure of the resultset would also
> imply failure of the
> present etc.
In real Z39.50 the result set status is returned
if and only if the search fails, to reflect the
status of possible partial results. However,
depending on what our result set model turns out
to be, result set existence in srw may be quite
different than in real Z39.50; we might want
result-set-status to reflect whether or not a
(stable) result set has been created, in the case
where the query suceeds and completes.
"LeVan,Ralph" wrote:
> I like the idea of the three statuses: search,
> result set and present.
Ralph, can you suggest a list of status value for
each of these?
And more generally, Ralph and Matthew (and others)
would you like to suggest a result set model?
Janifer Gatenby wrote:
> I would also like to see sort as an option
> within CQL, not a separate
> service.
Jan -- would you like to suggest what the sort
parameter would consist of? (First, I suppose we
need to see what our result set model will look
like.) As Ralph and others have noted, even
though a sort option would provide significant
potential for optimization we've long tried to do
it for Z39.50 and haven't been able to agree.
--Ray
|
