[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [search-ws] RE: cql-form issues checklist
Hi Ray:
Re your observations, I have these two comments:
> ****** Signalling the operation.
> (b) a searchRetrieve operation is signalled by the absence of the scanClause parameter.
I am sure that even Ralph must object to this. ;) This is so tenuous a signal of intent as not to merit any further real consideration.
> ******* 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:
I dislike all three suggestions you put forward (sorry!) because we are introducing additional complexity which we should be avoiding at all cost.
I had proposed a fairly simple mechanism to cater for those who did want an alternate boolean ordering - others would be unaffected. I would rather impose a set ordering than go for any of the three proposals you outline. No need to complexify further.
(I still don't understand the real objection to the use of a signed integer and suspect this has more to do with a phobia of number systems than anything else. Signed integer patterns are very common in programming. There is nothing unholy about them. It is not a black art.)
Cheers,
Tony
-----Original Message-----
From: Denenberg, Ray [mailto:rden@loc.gov]
Sent: Thu 12/23/2010 4:33 PM
To: 'OASIS SWS TC'
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
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]