At Mon, 3 Dec 2007 21:28:57 +0000,
"Dr R. Sanderson" <[log in to unmask]> wrote:
>
> Can we mandate that 'query' is CQL, but is optional, and any other query
> type can go in any number of other parameters, as specificed by the
> server?
>
> If, as a server, I receive 'query', I know a priori that it's CQL.
> Otherwise we're back to the annoying situation of having to retrieve
> the explain document every time just to find out that yes they did
> just call the query parameter 'query' like everyone else does.

Speaking only for myself, as somebody who has experience implementing
CQL but less so with SRU, I’d like to ask a few questions and say a
few things on multiple query types & parameterized queries.

First, I presume that there is some real world demand for parametrized
queries? In the document at [1] I see examples of use but no cases
where PQ is a better fit than CQL.

2. Looking at the table on pg. 8 of [1], regarding the second item, I
fail to see why ?queryId=n&name=japan is simpler than
?query=name%3Djapan. Do these have different semantics, because there
are additional, optional query parameters which are hidden behind
queryId? For example, perhaps in this case we have a query whose name
is Japan, but which contains additional parameters, such as
subject=’fishing’? If this is the case, I fail to see why this is more
restful, for the following reasons:

2 a. There is no way (that I see) to discover the available query ids
and the meaning that these query ids have.

2 b. The concept of a parameterized query seems to me a resource
deserving of its own URI, if it is something that carries as much
meaning as I read in this document.

3. From the same table, ‘Server may implement a specific query using
code’. The ‘no’ under CQL is false. There is no reason why one can’t
recognize a particular CQL query & implement it uniquely.

4. From the same: ‘Supports keyword search’. The no for CQL is again
false. In addition to the (slightly cumbersome) CQL query:
[cql.keywords any "keyword_a keyword_b"] one could simply define
cql.serverChoice to be cql.keywords and the = relation to mean any,
which allows for a CQL query ["keyword_a keyword_b"], which seems to
me rather simple.

5. Again from the table, ‘Expects server to maintain state between
client requests’. Why is this yes for CQL? The resultSetId is not
required.

6. Line 314: ‘The URL MUST have a abs_path_suffix of “/search”’ This
is just bizarre. Also, it is violated on line 324, where the
abs_path_suffix is ‘/search/’.

7. There is a lot of other information in that document which seems
out of place.

Moving along to multiple query types.

8. CQL is a fine query syntax. I myself have written a parser for a
simpler style of syntax which parses into a CQL-java parse tree, and
can then be outputted as CQL with no loss in meaning from the original
form.

9. Level 0 CQL is very easy to implement; Level 1 is only a little
harder.

10. There is no reason why particular implementations cannot expand
SRU to include support for, say, parameterized queries, as long as
they don’t stomp on the CQL support. I fail to see it is necessary to
specify multiple query types in the standard.

11. For these reasons, I see no reason why CQL should not continue to
be the only query syntax specified by SRU.

Notes.

1. <http://www.oasis-open.org/committees/download.php/25861/search-ws-param-query-1.0-draft1.pdf>

best,
Erik Hetzner