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

[Matthew Dovey <m.dovey@jisc.ac.uk>]

Actually, thinking on this a little - would a simpler solution be simply to allow query to be repeatable. 

e.g. 

http://server/searchRetrieve?query= title%20exact%20fish

could be  also sent as

http://server/searchRetrieve?query=title&query=exact&query=fish

(the server just assembles the values for query in the order supplied inserting whitespace).

Most server-side cgi will still cope with this (some need a little effort, e.g. the solution for php is here: http://www.php.net/manual/en/reserved.variables.get.php#92439)

Matthew

> -----Original Message-----
> From: Hammond, Tony [mailto:t.hammond@nature.com]
> Sent: 15 December 2010 15:48
> To: Ray Denenberg, Library of Congress; 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
> **********************************************************
> **********************
> ________________________________
> 
> 
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1170 / Virus Database: 426/3316 - Release Date: 12/14/10