[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 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]