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


> 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



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