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