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

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

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