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

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

Order is indeed an issue if you have mixed booleans.   If you have a number
of search clauses linked by booleans and either (a) all of the booleans are
AND, or (b) all of the booleans are OR; then you wouldn't have to worry
about order.  

But "A AND B OR C" is not the same as "B OR A AND C" 

> -----Original Message-----
> From: Matthew Dovey [mailto:m.dovey@jisc.ac.uk]
> Sent: Wednesday, December 15, 2010 5:22 PM
> To: LeVan,Ralph; Denenberg, Ray; Hammond,Tony; OASIS SWS TC
> Subject: RE: [search-ws] queryn: A proposal for SRU to facilitate forms
> processing
> 
> Order isn't an issue if the field names are unique.
> 
> It is more likely that the server will use code along the following
> form to create a parameter name and test for its value and existence
> than to parse the parameter name, so I'd argue against 0 padding:
> 
> query = "";
> n = 1;
> 
> while (req.getParameter("q"  + n  + ".trm") != null) {
>    query + =  " " + req.getParameter("q"  + n  + ".idx") +
>                         " " + req.getParameter("q"  + n  + ".rel") +
>                       " " + req.getParameter("q"  + n  + ".trm");
>    n++;
> }
> 
> Matthew
> 
> > -----Original Message-----
> > From: LeVan,Ralph [mailto:levan@oclc.org]
> > Sent: 15 December 2010 21:45
> > To: Ray Denenberg, Library of Congress; Matthew Dovey; Hammond,Tony;
> > OASIS SWS TC
> > Subject: RE: [search-ws] queryn: A proposal for SRU to facilitate
> > forms processing
> >
> > If the form had the field names as "q01.idx" for large forms, then
> > those servers that count of simple string sorting should be okay.
> >
> > That problem can be taken care of with a note for the queryType.
> >
> > Ralph
> >
> > > -----Original Message-----
> > > From: Ray Denenberg, Library of Congress [mailto:rden@loc.gov]
> > > Sent: Wednesday, December 15, 2010 4:35 PM
> > > To: LeVan,Ralph; 'Matthew Dovey'; Hammond,Tony; 'OASIS SWS TC'
> > > Subject: RE: [search-ws] queryn: A proposal for SRU to facilitate
> > forms
> > > processing
> > >
> > > Right.
> > > On second thought is q1.idx, etc. really orderable as a practical
> > matter? If
> > > there are more than 9 clauses it won't be sufficient to do a simple
> > string
> > > order. Is it reasonable to require the server to parse the
> parameter
> > name to
> > > get the integer part? Or do we need to come up with a different
> > scheme?
> > > Something like "q.[x].idx where it is the responsibility of the
> > > client
> > to
> > > ensure that [x] is lexically increasing in the order of occurrence
> > > of
> > the
> > > parameters."
> > > --Ray
> > >
> > > > -----Original Message-----
> > > > From: LeVan,Ralph [mailto:levan@oclc.org]
> > > > Sent: Wednesday, December 15, 2010 12:13 PM
> > > > To: Denenberg, Ray; Matthew Dovey; Hammond,Tony; OASIS SWS TC
> > > > Subject: RE: [search-ws] queryn: A proposal for SRU to facilitate
> > forms
> > > > processing
> > > >
> > > > Yes.  My comment was in response to Matthew's suggestion that
> > instead
> > > > the parameter name simply be repeating "query".
> > > >
> > > > Ralph
> > > >
> > > > > -----Original Message-----
> > > > > From: Ray Denenberg, Library of Congress [mailto:rden@loc.gov]
> > > > > Sent: Wednesday, December 15, 2010 12:06 PM
> > > > > To: LeVan,Ralph; 'Matthew Dovey'; Hammond,Tony; 'OASIS SWS TC'
> > > > > Subject: RE: [search-ws] queryn: A proposal for SRU to
> > > > > facilitate
> > > > forms
> > > > > processing
> > > > >
> > > > >
> > > > >   &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
> > > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > ---------------------------------------------------------------------
> > > > To unsubscribe from this mail list, you must leave the OASIS TC
> > > > that generates this mail.  Follow this link to all your TCs in
> OASIS at:
> > > >
> > https://www.oasis-
> > open.org/apps/org/workgroup/portal/my_workgroups.php
> > >
> >
> >
> >
> >
> > ________________________________
> >
> > No virus found in this message.
> > Checked by AVG - www.avg.com
> > Version: 10.0.1170 / Virus Database: 426/3317 - Release Date:
> 12/15/10