****** Signalling the operation.
We note in the section about operations that this is all a heuristic exercise at best and that as soon as the day comes when there is another operation defined, this will all have to be rewritten, so I don't think it is really all that tenuous, and it certainly is deterministic - the scanClause is mandatory in a scan request and there are only two operations, scan and searchResponse (there is explain but it is a pseudo operation) so it has to be one or the other.
******* Pre vs. post booleans
I am against the negative numbe approach for two reasons, one, the overloading, and two, if the value of a parameter is a number then that number should represent the intended value. As Cliff Lynch used to say there is a conservation of complexity principle here. You introduce just as much complexity either way so why not take the most handsome approach.
--Ray
From: Hammond, Tony [mailto:t.hammond@nature.com]
Sent: Thursday, December 23, 2010 2:27 PM
To: Denenberg, Ray; OASIS SWS TC
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
********************************************************************************
DISCLAIMER: This e-mail is confidential and should not be used by anyone who is
not the original intended recipient. If you have received this e-mail in error
please inform the sender and delete it from your mailbox or any other storage
mechanism. Neither Macmillan Publishers Limited nor any of its agents accept
liability for any statements made which are clearly the sender's own and not
expressly made on behalf of Macmillan Publishers Limited or one of its agents.
Please note that neither Macmillan Publishers Limited nor any of its agents
accept any responsibility for viruses that may be contained in this e-mail or
its attachments and it is your responsibility to scan the e-mail and
attachments (if any). No contracts may be concluded on behalf of Macmillan
Publishers Limited or its agents by means of e-mail communication. Macmillan
Publishers Limited Registered in England and Wales with registered number 785998
Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS
********************************************************************************