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

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

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