Tony Linde ael at star.le.ac.uk
Tue Mar 2 08:50:16 PST 2004

```        a:  T T T T F F F F

b:  T T F F T T F F

c:  T F T F T F T F

a||b:  T T T T T T F F

b||c:  T T T F T T T F

(a||b)||c:  T T T T T T T F

a||(b||c):  T T T T T T T F

They look the same to me!

Cheers,
Tony.

> -----Original Message-----
> From: Ed Shaya [mailto:Edward.J.Shaya.1 at gsfc.nasa.gov]
> Sent: 02 March 2004 16:22
> To: Tony Linde
> Cc: voql at ivoa.net
>
>
>
> Tony Linde wrote:
>
> >Hi Ed,
> >
> >In logic terms, aren't 'a OR b OR c', 'a OR (b OR c)' and
> '(a OR b) OR c'
> >the same? Ie, evaluates to true if any of a, b & c are true
> and false
> >if all of them are false.
> >
> >
> >
> Of course not.  In the last one a can be false and if b and c
> are true, the statement is true.  In the middle one, a must
> be true and either b or c can be false for the statement to
> be true.  In the first one, one needs a rule to resolve which
> of the two it is.
>
> Ed
>
> >Cheers,
> >Tony.
> >
> >
> >
> >>-----Original Message-----
> >>From: Ed Shaya [mailto:Edward.J.Shaya.1 at gsfc.nasa.gov]
> >>Sent: 02 March 2004 15:36
> >>To: Tony Linde
> >>Cc: voql at ivoa.net
> >>
> >>
> >>
> >>Tony Linde wrote:
> >>
> >>
> >>
> >>>>P48 scalar_exp -> scalar_exp DIV scalar_exp ;
> >>>>
> >>>>This would be a bit of a dilemma for DIV to be 2..*
> >>>>
> >>>>
> >>>>
> >>>>
> >>>I was only referring to intersection and union searches but
> >>>
> >>>
> >>why is DIV
> >>
> >>
> >>>a problem? The statement
> >>> a / b / c / d
> >>>is perfectly valid. It is up to the interpreter what is
> done with it.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>I think the BNF allows
> >>>>exp1 AND exp2 AND exp3 to be created by 2 AND statements.
> >>>>
> >>>>
> >>If you want
> >>
> >>
> >>>>(exp1 AND exp2) AND exp3 then you need to put in OPAREN
> and CPAREN.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>I still don't see why there is a problem with changing the
> >>>
> >>>
> >>cardinality
> >>
> >>
> >>>to
> >>>2..* - it is certainly consistent with the intent of the SQL
> >>>
> >>>
> >>BNF - the
> >>
> >>
> >>>BNF only has two arguments because that is the way BNF works - the
> >>>*intent* is that 'a AND b AND c AND d' is a valid statement
> >>>
> >>>
> >>- and given
> >>
> >>
> >>>the number of wholesale changes made in the
> simplification, it seems
> >>>perverse not to make this one.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>I do agree with you.  As long as ADQL transforms directly
> >>into valid SQL  and vice-versa there is no reason not to
> >>allow it.  The BNF can not fully guide this transformation
> >>because XML was not invented  when BNF was and we are
> >>switching to a sort of reverse polish notation for the XML
> >>which, again, the BNF does not address.
> >>
> >>It also occurs to me that in a series of ANDs if the
> >>implementation follows left to right, it does not matter
> >>where the parentheses are.
> >>The series of expressions are evaluated starting from the
> >>left and when it reaches a false expression, it stops.  If
> >>the implementation allows for optimal strategy, the system
> >>will evaluate in its own order and again the parentheses do
> >>not matter.
> >>So AND with unbounded cardinality seems fine to me. Likewise
> >>with PLUS.
> >>
> >>With ORs the parentheses do matter and we need to decide if <OR>
> >>    exp1
> >>    <OR>
> >>       exp2
> >>       exp3
> >>     </OR>
> >></OR>
> >>means "exp1 OR exp2 OR exp3"  (ie. if you want parentheses
> >>you need to put them in), which is then interpreted as (exp1
> >>OR exp2) OR exp3.
> >>Or, does it mean "exp1 OR (exp2 OR exp3)" (ie, nesting
> >>implies parentheses)?
> >>As ADQL stands, one can not tell definitively.
> >>I would think that for OR you want cardinality of 2 and
> >>nesting implies parentheses because it forces one to
> >>explicitly indicate the logical statement truly intended.  I
> >>can't see how that could ever be bad. SQL implementations
> >>that permit optimal strategies can still evaluate the expN in
> >>whatever order they wish so long as in the end the result is
> >>the same.  Likewise with DIV.
> >>
> >>Ed
> >>
> >>
> >>
> >>
> >>Ed
> >>
> >>
> >>
> >>>Cheers,
> >>>Tony.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>-----Original Message-----
> >>>>From: Ed Shaya [mailto:Edward.J.Shaya.1 at gsfc.nasa.gov]
> >>>>Sent: 01 March 2004 21:56
> >>>>To: Tony Linde
> >>>>Cc: voql at ivoa.net
> >>>>
> >>>>
> >>>>
> >>>>Tony Linde wrote:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>>Hence, we should not change cardinality of operators in the
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>XSD since
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>>this can not be supported by SQL.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>It can be supported by SQL as the .ycc file indicates. The
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>definition:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>P29 search_condition -> search_condition AND search_condition;
> >>>>>
> >>>>>shows that any search condition could be
> >>>>>
> >>>>>a AND b AND c AND d AND ...
> >>>>>
> >>>>>and that imposing brackets where they are not explicitly stated:
> >>>>>
> >>>>>a AND (b AND (c AND (d AND ... ))...)
> >>>>>
> >>>>>is actually misrepresenting the SQL.
> >>>>>
> >>>>>It would be like taking:
> >>>>>
> >>>>>P45 scalar_exp -> scalar_exp PLUS scalar_exp ;
> >>>>>P47 scalar_exp -> scalar_exp MULT scalar_exp ;
> >>>>>
> >>>>>To mean that a * b + c must be represented as a * (b +
> c) which is
> >>>>>definitely wrong.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>Hmm.
> >>>>
> >>>>P48 scalar_exp -> scalar_exp DIV scalar_exp ;
> >>>>
> >>>>This would be a bit of a dilemma for DIV to be 2..*
> >>>>
> >>>>I think the BNF allows
> >>>>exp1 AND exp2 AND exp3 to be created by 2 AND statements.
> >>>>
> >>>>
> >>If you want
> >>
> >>
> >>>>(exp1 AND exp2) AND exp3 then you need to put in OPAREN
> and CPAREN.
> >>>>
> >>>>Ed
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>So, allowing cardinality of 2..* in the ADQL/x version is
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>actually the
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>better representation of the SQL.
> >>>>>
> >>>>>Cheers,
> >>>>>Tony.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>-----Original Message-----
> >>>>>>From: Vivek Haridas [mailto:haridas at cs.jhu.edu]
> >>>>>>Sent: 01 March 2004 20:22
> >>>>>>To: Tony Linde
> >>>>>>Cc: voql at ivoa.net
> >>>>>>
> >>>>>>
> >>>>>>The string form of ADQL defined by
> >>>>>>is the standard for ADQL.
> >>>>>>
> >>>>>>The XML schema needs to be able to express any string
> >>>>>>facilitate parsing.
> >>>>>>
> >>>>>>I will soon post the steps taken to produce the XSD.
> >>>>>>
> >>>>>>My opinion is that We should not attempt to alter SQL
> >>>>>>
> >>>>>>
> >>beyond making
> >>
> >>
> >>>>>>
> >>>>>>Hence, we should not change cardinality of operators in the
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>XSD since
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>>this can not be supported by SQL.
> >>>>>>
> >>>>>>with Best Regards,
> >>>>>>Vivek
> >>>>>>
> >>>>>>
> >>>>>>On Mon, 1 Mar 2004, Tony Linde wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>We don't seem to be getting far on the ADQL v0.7.3
> >>>>>>>
> >>>>>>>
> >>discussions. My
> >>
> >>
> >>>>>>>main concerns are about 'proving' the validity of the
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>simplification
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>and how we manage ADQL in the future.
> >>>>>>>
> >>>>>>>We need a clear statement of how the current v0.7.3 is
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>generated (and
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>also how v0.7.1 aka 0.8 was generated). It seems that a
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>SQL-92 BNF -
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>SELECT only
> >>>>>>>- was put through some tool which created an xml
> schema version,
> >>>>>>>BNF/x. This was then modified to add cross match and region
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>This, effectively was the v0.7.1 version. This version was
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>them 'simplified'
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>by losing some of the common structures (eg Search type) and
> >>>>>>>coalescing stacked elements into single ones; lets call
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>Is this a correct summary?
> >>>>>>>
> >>>>>>>If we're to standardise ADQL and we want the BNF to
> >>>>>>>
> >>>>>>>
> >>remain as the
> >>
> >>
> >>>>>>>core, we need to document and/or automate each of these
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>transitions.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>All of the /x
> >>>>>>>--> /x transitions can be automated using XSLD, and the BNF
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>--> BNF/x
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>--> is
> >>>>>>>automated using the tool.
> >>>>>>>
> >>>>>>>Could Wil or Vivek please provide us with:
> >>>>>>>1. what is the exact BNF used and where was it sourced and
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>how modified?
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>1. what is the name/location of the tool used to convert
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>the BNF to BNF/x?
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>simplified
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>>>
> >>>>>>>It doesn't make sense to me to introduce the extensive
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>changes in the
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>--> ADQL/sx transition yet to say that changing the
> >>>>>>>
> >>>>>>>
> >>cardinality of
> >>
> >>
> >>>>>>>intersection & union searches from 2 to 2..* is invalid.
> >>>>>>>
> >>>>>>>Another question is how we manage the string version of
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>It should be a simple matter to convert a single instance
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>query
> >>>>>>>
> >>>>>>>
> >>people want to
> >>
> >>
> >>>>>>>allow *direct entry* of the string version of ADQL and to
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>then we will need some way of generating a new BNF that
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>corresponds to
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>method so
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>that future extensions can be incorporated easily.
> >>>>>>>
> >>>>>>>Cheers,
> >>>>>>>Tony.
> >>>>>>>
> >>>>>>>__
> >>>>>>>Tony Linde
> >>>>>>>Phone:  +44 (0)116 223 1292    Mobile: +44 (0)7753 603356
> >>>>>>>Fax:    +44 (0)116 252 3311    Email:  ael at star.le.ac.uk
> >>>>>>>Post:   Department of Physics & Astronomy,
> >>>>>>>      University of Leicester
> >>>>>>>      Leicester, UK   LE1 7RH
> >>>>>>>
> >>>>>>>Project Manager,            Director,
> >>>>>>>AstroGrid                   Leicester e-Science Centre
> >>>>>>>http://www.astrogrid.org    http://www.e-science.le.ac.uk/
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >>>
> >>>
> >
> >
> >
>

```