RE: [search-ws] queryn: A proposal for SRU to facilitate forms processing

["Hammond, Tony" <t.hammond@nature.com>]

Title: RE: [search-ws] queryn: A proposal for SRU to facilitate forms processing

Hi Ray:

> so let's say 'cql-form' for now (and decide later).

:)

> But I find the queryn parameter very akward, I think for the same reason as Matthew, it's primary purpose being to signal that the entire request is to
be interpreted in a different manner, and further that it is overloaded with a secondary purpose, to indicate the number of clauses, which I find superfluous as that can be determined simply by parsing the request.

There are 3 things that may be required - you list only two.

1. query type - I'm easy on this but understand some may prefer an explicit distinction between 'cql' and 'cql-form'

2. number of clauses - which *can* be determined by the query builder but shouldn't have to be - I see nothing wrong (and only gains) with an explicit count

3. operation - the thing you didn't mention but which you mentioned earlier

My rationale for "queryn" parameter is primarily because it supports #3 - it acts as counterpart for regular "query" parameter. Remember we did away with "operation" parameter - or deprecated it or something. So now search operation is predicated on presence of "query" or (I would say) "queryn".

I think it's helpful to have an explicit count set and for that reason a parameter to encode that.

Am willing to concede that we shouldn't overload the query type (if indeed we need to distinguish 'cql-form' from 'cql'). In that case the "queryType" parameter should be required.

So I believe that for reasons #3 and #2 there is a purpose in a standalone "queryn" parameter.

Tony



-----Original Message-----
From: Ray Denenberg, Library of Congress [mailto:rden@loc.gov]
Sent: Wed 12/15/2010 4:32 PM
To: Hammond, Tony; 'Matthew Dovey'; 'LeVan,Ralph'; 'OASIS SWS TC'
Subject: RE: [search-ws] queryn: A proposal for SRU to facilitate forms processing

'fbcql' was just a placeholder, we can call it whatever you like,  so let's
say 'cql-form' for now (and decide later).



But I find the queryn parameter very akward, I think for the same reason as
Matthew, it's primary purpose being to signal that the entire request is to
be interpreted in a different manner, and further that it is overloaded with
a secondary purpose, to indicate the number of clauses, which I find
superfluous as that can be determined simply by parsing the request.

--Ray





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



Hi:

I would have been more inclined to retain the "queryn" parameter. That way
one could have

    searchRetrieve = query | queryn

And that becomes easy to test for the searchRetrieve operation. Do you gave
a parameter named query*?

The parameter "query" has the actual data by value, whereas the parameter
"queryn" is more like data by reference - the number is not dissimilar from
a location - the count is used in fact to locate the parameters within the
parameter space.

Whether one also needs to have the "queryType", I could live with that - if
it's really required. But I can't readily live with the string "fbcql".
Can't it be something more down to earth like "cql-lite" or "cql-simple" or
even "cql-form", or of that ilk? Let's keep the branding "cql" up front, and
use a word rather than a token. (We do have "xcql" but that is exclusively
for XML. I wouldn't feel any requirement to follow the naming here.)

Tony



-----Original Message-----
From: Ray Denenberg, Library of Congress [mailto:rden@loc.gov]
Sent: Wed 12/15/2010 3:35 PM
To: 'Matthew Dovey'; Hammond, Tony; 'LeVan,Ralph'; 'OASIS SWS TC'
Subject: RE: [search-ws] queryn: A proposal for SRU to facilitate forms
processing

Suppose instead:

 - define a new query type, let's call it fbcql for now.
 - when queryType=fbcql, then there is no query parameter and instead, it is
a signal that these form-based parameters will occur.
 - so there is no need for the queryn parameter.

This approach does mean changing the protocol so that the query parameter is
not mandatory (it would be omitted in this special case) but I am not
terribly offended by such a change.

Is this an acceptable compromise?

--Ray

> -----Original Message-----
> From: Matthew Dovey [mailto:m.dovey@jisc.ac.uk]
> Sent: Wednesday, December 15, 2010 7:06 AM
> To: Hammond, Tony; Denenberg, Ray; LeVan,Ralph; OASIS SWS TC
> Subject: RE: [search-ws] queryn: A proposal for SRU to facilitate forms
> processing
>
> > Yes, you have understood my proposal correctly. :)
> >
> > I would question though whether we really need to assign a different
> > queryType as this is a strict subset of CQL.
>
> And that's where we differ ;-)
>
> I think what we can agree on is that we have a concept of "query
> language" and "query encoding". The query language we are talking about
> in all cases is CQL. We currently have a string encoding for CQL. We
> did have an XML encoding for CQL (I can't recall if we kept it but its
> usefulness turned out to be limited). You are proposing a form-based
> encoding for CQL.
>
> However, we only have one parameter queryType. You think that queryType
> should indicate the query language but not the encoding, whereas I'm
> quite happy with queryType indicating both the query language *and* the
> encoding for that language.
>
> On the other hand, I'm not too happy about the query encoding being
> determined by the presence (or absence) of an overloaded parameter in
> the request (queryn does two things - indicates the number of clauses
> *and*by its presence indicates that the query encoding is form based).
> I would much rather the query encoding be explicitly indicated by the
> value of a parameter (and defaulted is the parameter is omitted).
>
> I think, I'm arguing that we perhaps need to replace queryType with two
> parameters: queryLanguage and queryEncoding but I'm concerned that is
> over-engineering.
>
> Matthew




****************************************************************************
**** 
DISCLAIMER: This e-mail is confidential and should not be used by anyone who
is
not the original intended recipient. If you have received this e-mail in
error
please inform the sender and delete it from your mailbox or any other
storage
mechanism. Neither Macmillan Publishers Limited nor any of its agents accept
liability for any statements made which are clearly the sender's own and not
expressly made on behalf of Macmillan Publishers Limited or one of its
agents.
Please note that neither Macmillan Publishers Limited nor any of its agents
accept any responsibility for viruses that may be contained in this e-mail
or
its attachments and it is your responsibility to scan the e-mail and
attachments (if any). No contracts may be concluded on behalf of Macmillan
Publishers Limited or its agents by means of e-mail communication. Macmillan

Publishers Limited Registered in England and Wales with registered number
785998
Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS 
****************************************************************************
****