[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [search-ws] queryn: A proposal for SRU to facilitate formsprocessing
You missed the point.
If the parameter names are unique neither the server doesn't to worry whether it can sort the parameters by string sorting or not since the most obvious code for the server to build the CQL from cql-form would be code of the following form:
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++;
}
which works fine even when there are more than 9 terms or even more than 99 terms.
Matthew
> -----Original Message-----
> From: Ray Denenberg, Library of Congress [mailto:rden@loc.gov]
> Sent: 15 December 2010 22:32
> To: Matthew Dovey; 'LeVan,Ralph'; Denenberg, Ray; 'Hammond,Tony';
> 'OASIS SWS TC'
> Subject: RE: [search-ws] queryn: A proposal for SRU to facilitate forms
> processing
>
> 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
>
>
>
> ________________________________
>
> 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]