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