I don't think this is "all a step too far" and I believe that the sole issue is whether pre-processing needs to be exposed as part of the protocol model, or can it be treated as a guidance in a non-normative annex. If we can do the latter than we can move this along. --Ray From: Hammond, Tony [mailto:t.hammond@nature.com]
Sent: Sunday, January 09, 2011 8:50 AM
To: Denenberg, Ray; LeVan,Ralph; OASIS SWS TC
Subject: RE: [search-ws] Call Monday, January 10; cql-form options The "cql-form" problem, as I see it, is the notion of supporting *distributed* queries, i.e. queries with components that are scattered across multiple parameters.
Earlier we only had the notion of alternative query types which would present their respective query strings within a *single* parameter - "query".
On the back of delivering queries direct from a web form we are now looking to generalize a formalism which would allow for fragmented queries. That has led to the idea that the monolithic query string presented in a dedicated parameter "query" is, in fact, a special case. On that basis, the parameter "query" is now being demoted to a "queryType" specific parameter.
Recovery of the query previously required an interpretation of "queryType" to get the right "read" of the query string in the known parameter "query". The current proposals now mean that "queryType" needs to be interpreted to first locate the parameters (and the construction rules) required to *assemble* the query even before getting the right "read" on that query.
I am willing to concede that this may all be a step too far for SRU. But I am not willing to concede that without it SRU (like other query technologies) does not reach to the web form and that preprocessing (at client or server) is required before SRU steps in.
Tony
|