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

["Ray Denenberg, Library of Congress" <rden@loc.gov>]

  &q1.idx=index1
  &q1.rel=relation1
  &q1.trm=term1
  &q1.bln=boolean1
  &q2.idx=index2
  &q2.rel=relation2
  &q2.trm=term2
  &q2.bln=boolean2

Aren't these are sufficiently orderable?

> -----Original Message-----
> From: LeVan,Ralph [mailto:levan@oclc.org]
> Sent: Wednesday, December 15, 2010 11:50 AM
> To: Matthew Dovey; Hammond,Tony; Denenberg, Ray; OASIS SWS TC
> Subject: RE: [search-ws] queryn: A proposal for SRU to facilitate forms
> processing
> 
> 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
> >