[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [search-ws] Call Monday, January 10; cql-form options
> We're trying to solve the cql-form problem. Sorry, that's a little vague. I'm really not trying to be difficult here. It's just that this conversation has gone on for a while and I really don't know where we are. As far as I'm concerned, cql-form is a solved problem. queryType="cql-form" and the components of the query come in as q** parms. The addition of query types that do not require a "query" parameter does raise some problems. Two come to mind immediately: 1) What do we say about the "query" parameter in the standard? 2) How do we recognize a searchRetrieve request in the absence of a "query" parameter? I think the question you raise below is #3 3) should query processing be modeled in SRU? I claim that the answer is "no". We probably need to acknowledge the existence of a database service in our model and relegate the processing of queries to the database. We absolutely do NOT want to add a preprocessing step to our model whose only purpose is to convert non-CQL queries into CQL queries. Not all queryTypes will be convertible into CQL. > Where we left of (before my > message yesterday) was that Tony had suggested that he wanted it modeled in > terms of pre-processing. So that the query would be transmitted via > parameters, i.e. in "form' form, and then the server would convert those > parameters into a cql query, and process it as a conventional cql query. > > What we don't understand is: is this conversion (a) supposed to be visible > to the protocol, or (b) is it something that the server is free to do if it > chooses but is invisible to the protocol. > > You (Ralph) and I balk at the prospect of (a), and we are not clear what > Tony's position is, but it seems that that is what he is advocating, an > explicit modification to the protocol model to accommodate this conversion. > Tony will have to weigh in. > > The other issue was .... > > To remove the query parameter or not. You (Ralph) suggested that we can > eliminate the query parameter and make it a query-specific parameter, > specifically, THE query-specific parameter for CQL. While I initially went > along with the idea, Tony objected, and I agree with his objection. That's problems 1 and 2 rolled together. Let's split them apart. Ralph
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]