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