If we are going to do this we need to move it along. That is, we need firm agreement on all outstanding issues so we can get the documents finished. On signalling the operation: let's say presence of EITHER query or queryType signals searchRetrieve and presence of scanClause signals Scan. Ok? On pre vs. post booleans; this one is slightly less important to resolve immediately because it is an annex in CQL, and if we get all the SRU details out of the way at least we can finish that off, but this one is more difficult because I remain opposed to overloading the parameter in the manner proposed. It just makes sense to me to add another parameter than to have to have complex semantics like "take the absolute value to determine the maximum number of clauses, and then to determine whether the booleans are pre or post ……. ". I don't see how that reduces overall complexity. --Ray From: Hammond, Tony [mailto:t.hammond@nature.com] Sent: Friday, December 24, 2010 6:55 AM To: Denenberg, Ray; OASIS SWS TC Subject: RE: [search-ws] RE: cql-form issues checklist Hi Ray:
> ****** Signalling the operation.
We seem to have followed heuristics all the way down the ladder:
* explicit signal - presence of parameter (operation) * implicit signal (positive) - presence of parameter (query) * implicit signal (negative) - absence of parameter (scanClause)
This isn't going in a good direction. I don't think the word "tenuous" is inappropriate.
> ******* Pre vs. post booleans
> if the value of a parameter is a number then that number should represent the intended value
The number in queryn does represent the number of clauses. The sign merely changes the axis - *not* the value (i.e. magnitude). This is basic math.
Tony
-----Original Message----- From: Ray Denenberg, Library of Congress [mailto:rden@loc.gov] Sent: Thu 12/23/2010 8:02 PM To: 'OASIS SWS TC' Subject: RE: [search-ws] RE: cql-form issues checklist
****** 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 **************************************************************************** ****
|