OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

search-ws message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]