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

["LeVan,Ralph" <levan@oclc.org>]

Order is not guaranteed by forms encoders.  Typically, it is the reverse
of the order in the form, but not guaranteed.  In the original Google
example, order was not important.  Here it is and the only guarantee of
order would be by picking parameter names that are orderable.

Ralph

> -----Original Message-----
> From: Matthew Dovey [mailto:m.dovey@jisc.ac.uk]
> Sent: Wednesday, December 15, 2010 11:26 AM
> To: Hammond,Tony; Ray Denenberg, Library of Congress; LeVan,Ralph;
OASIS
> SWS TC
> Subject: RE: [search-ws] queryn: A proposal for SRU to facilitate
forms
> processing
> 
> 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
>