OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

search-ws message

[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


We may need to agree to differ.

For the sake of simplicity, I'm going to call your cql variant fbcql (for forms-based cql)

> > To me the queryType parameter instructs the SRU server which parser it
> should use to read the incoming query.
> 
> I would agree with that to the extent that the query string is read from the
> "query" parameter. From Sect. 5:
> 
>     "The request parameter queryType is a string indicating the query language
> supplied in the parameter 'query'"
> 
> What I proposed was a *prerocessing* step an SRU server could take to
> *assemble* the query string into the parameter "query" so that it could be
> read by the parser indicated by queryType ("cql" by default).
> 
> So, according to the current spec the proposal is covered by "queryType=cql"
> allowing that a reassmbly mechanism required by presence of "queryn"
> parameter has been activated.

I'd much rather have queryType=fbcql indicate that the query is not passed via the query parameter but via an alternative means. This may mean some alteration to the base specification to the effect that queryType can override how the query is sent to the server. This may have other possible uses (e.g. if the query data is via a data stream or is too large to send via a typically http request).

This then (rightfully imho) leaves it up to the server how to process the incoming message. It can if it likes convert fbcql to cql and then convert the cql to whatever the internal search engine needs; or it could convert fbcql directly to the internal search engine bypassing cql entirely.

I'd also argue that the queryn parameter is redundant, in that the server code could be something like

for (n = 1; requestParameters.contains("qi"+n); n++) {
   do something...
}

I'd be more inclined to regard this as a pre-processor if it was queryType independent - i.e. if there was a generic approach which could convert from a form to a query string which could be applied regardless if the queryType was cql, sql, sparql etc.

Matthew


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]