[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [search-ws] RE: cql-form issues checklist
I fully agree with Matthew. Alternate query strings were meant to sit within the query parameter, and queryType was meant to invoke an alter query processor.
In fact the notion of additional queryType parameters only arose because we were considering how to deal with a distributed *CQL* query. In essence the same type of query, albeit scattered here, there and everywhere. But in view of the need for preprocessing to assemble the query, and also (as Matthew earlier pointed out) that we were dealing with a subset of CQL then it was deemed better that we treat this as a new query type.
But we hadn't got to the point of considering non-CQL queries with their own dedicated parameter sets, although the new views on queryType might seem to encourage that.
Tony
-----Original Message-----
From: Matthew Dovey [mailto:m.dovey@jisc.ac.uk]
Sent: Thu 12/23/2010 9:39 AM
To: LeVan,Ralph; Hammond, Tony; Denenberg, Ray; OASIS SWS TC
Subject: RE: [search-ws] RE: cql-form issues checklist
>The query parameter is defined by the CQL queryType to carry a CQL query.
>We shouldn't decide that now it carries other stuff when the queryType is not CQL.
That is how I understood the situation, nor does it reflect any suggestions *I*'ve written re proposed changes to queryType behaviour.
Prior to the cql-form discussion, queryType defined the syntax of the data passed in the query parameter. If I wanted to send a SPARQL query you would specify the appropriate queryType but still send the query in the query parameter.
My articulation of the change was that queryType could *optionally* define different parameters, not that it must do so. Hence in the above SPARQL example, the query parameter would still be used.
However, you seem to be saying a different queryType *must* define a parameter other than query, so for the SPARQL example, I'd have to define a parameter called "sparqlquery". Could another queryType reuse this parameter? If not, how would we control that? If it would does thia mean CQL has a special status that prevents its query parameter being re-used?
In any case, the above are only proposed changes. The current spec is that queryType defines the content of the query parameter. My new proposal is that the query is still passed via the queryType parameter, but depending on the queryType may use additional parameters too.
Matthew
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]