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] 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]