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

["Hammond, Tony" <t.hammond@nature.com>]

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

>  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.

There is a certain coplexity in this whichever way it is implemented - or not. And yes, also if not implemented that causes complexity because then one may be called on to justify why a given boolean order was selected.

I had aimed for a practical solution which seems to have met with some resistance. I think you may be talking this up just a little, Ray. Most of the semantics is already there in half a sentence as you've just shown. And remember a (minus) sign would only ever show up if a user selected for the alternate boolean ordering. So would be easier on the reader just to say that the value is an integer and the magnitude is eaual to the maximum number of search clauses, and then to add that if a minus sign is present then the order is reversed. No biggie.

Never mind.

We certainly do not need another parameter. Easy to process, but complex to manage. Needs identifier, documentation, etc.

Logically an alternate queryType would be the place to locate this. But again more complexity in managing this. Needs identifier, documentation, etc.

So, I am against new parameter and also new queryType, and if the overloading is too much would just go for a fixed (post) boolean ordering.

Tony


-----Original Message-----
From: Ray Denenberg, Library of Congress [mailto:rden@loc.gov]
Sent: Mon 12/27/2010 3:39 PM
To: 'OASIS SWS TC'
Subject: RE: [search-ws] RE: cql-form issues checklist

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
****************************************************************************
****