[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [search-ws] RE: cql-form issues checklist
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]