-----Original Message----- From: Ray Denenberg, Library of Congress [mailto:rd...@loc.gov] Sent: 14 December 2010 20:03 To: 'Hammond, Tony'; Matthew Dovey; 'LeVan,Ralph'; 'OASIS SWS TC' Subject: RE: [search-ws] queryn: A proposal for SRU to facilitate forms processing

Tony - forgive me for being dense but I don't completely understand what is proposed. So let's go back to square one.

Would a query go over the wire, where:

queryType=cql (or omitted as default)

&queryn=2

&q1.idx=index1

&q1.rel=relation1

&q1.trm=term1

etc.

&query= WHAT?????

would there be a real (redundant) cql query in the cql parameter. Or what?

If the queryType is 'cql' (default or explicitly) and the query does not contain what we know to be a cql query, then this is a radical departure from the current spec.

I honestly cannot tell if this is what you're proposing.

When you say: 'Whether the query travels wholesale through a single "query" parameter or is split up over mutiple querylets (can I use that word? :) as signalled by a "queryn" parameter does not affect the query itself.'

I don't know what to make of that statement. The purpose of the protocol is (a) to tell the server what the query type is, and (b) to present a query of THAT TYPE in the query parameter.

When you say:

"What I proposed was a *prerocessing* step an SRU server could take to *assemble* the query string into the parameter "query" so that it could be read by the parser indicated by queryType ("cql" by default)."

Then I really get worried. This seems completely counter to the protocol model that we know and love.

Don't get me wrong, I'm not trying to dismiss the idea altogether, but I would like to see it done in a manner consistent with protocol principles that we all agree with.

--Ray

From: Hammond, Tony [mailto:t.ha...@nature.com] Sent: Tuesday, December 14, 2010 5:44 AM To: Matthew Dovey; Denenberg, Ray; LeVan,Ralph; OASIS SWS TC Subject: RE: [search-ws] queryn: A proposal for SRU to facilitate forms processing

Hi Matthew:

should use to read the incoming query.

I would agree with that to the extent that the query string is read from the "query" parameter. From Sect. 5:

"The request parameter queryType is a string indicating the query language supplied in the parameter 'query'"

What I proposed was a *prerocessing* step an SRU server could take to *assemble* the query string into the parameter "query" so that it could be read by the parser indicated by queryType ("cql" by default).

So, according to the current spec the proposal is covered by "queryType=cql" allowing that a reassmbly mechanism required by presence of "queryn" parameter has been activated.

It could be argued that there might be countless preprocessing steps, but this I believe - assembly from web form input - occupies a special position in that it is intimately bound to current web technologies for user input.