RE: [search-ws] RE: cql-form issues checklist

["Denenberg, Ray" <rden@loc.gov>]

Thanks all, for the comments, I was away from the office yesterday, I have read all of yesterday's messages (some from this morning) and here are my observations.


****** Signalling the operation.  
I do NOT favor making either the query or queryType parameter mandatory.
Either: 
(a) a searchRetrieve operation is signalled by the presence of either the query or queryType parameter.
Or (this will work):
(b) a searchRetrieve operation is signalled by the absence of the scanClause parameter.


********** name of the query
I suppose the only name that we all find acceptable is cql-form, so I suppose that's the winner.

(I'm not wild about it, I still think cql-p is better. I do not like cql-lite, cql-simple, or anything along those lines.)


***** cql-lite
I do understand Tony's point about a lite cql specification as a reference for the cql-form query. I suggest that we take a look at the cql conformance section and think about whether instead of a separate cql-lite spec, it could be a separate conformance level. 


************  queryn vs. queryN
queryn if fine.


******* Pre vs. post booleans
I'm prepared to accept that we need to distinguish these. I still stongly dislike letting queryn take on a negative value. So let's examine other alternatives:
 1. Different parameter names: queryn and querym.
 2. Yet one more parameter, boolean: boolean=pre or boolean=post
 3. different query types.  cql-formn and cqlformm
I'm not really very serious about 3, I think 2 is best. 


***** whose spec is it, anyway?
I agree with Tony that this is not Tony's spec it is our spec.


********* bnf
my appologies, I just haven't had time to look at it, and won't until next week but I will look at it next week.


**** Normative or non?
As cql-form, this is going to be closely associated with cql. We're not proposing this as part of SRU, and the impact on SRU is fairly non-intrusive (have to allow for a query to impose random, unspecified parameters).  We are proposing this as an annex for CQL, not SRU. As such, I believe that as long as we can nail it down so that it is technically sound it is appropriate to make it normative. 


--Ray