ADQL v0.7.3
Tony Linde
ael at star.le.ac.uk
Tue Mar 2 07:54:42 PST 2004
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.
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
> Subject: Re: ADQL v0.7.3
>
>
>
> 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
> >>Subject: Re: ADQL v0.7.3
> >>
> >>
> >>
> >>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
> >>>>Subject: Re: ADQL v0.7.3
> >>>>
> >>>>
> >>>>The string form of ADQL defined by
> >>>>the BNF (http://www.ivoa.net/internal/IVOA/IvoaVOQL/adql.ycc)
> >>>>is the standard for ADQL.
> >>>>
> >>>>The XML schema needs to be able to express any string in ADQL to
> >>>>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
> >>>>our astronomy additions (Xmatch,region)
> >>>>
> >>>>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
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>capability, giving ADQL/x.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>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
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>this ADQL/sx.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>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?
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>2. what modifications were made to convert BNF/x --> ADQL/x?
> >>>>>3. what modifications to ADQL/x were made to produce the
> >>>>>
> >>>>>
> >>simplified
> >>
> >>
> >>>>>version, ADQL/sx?
> >>>>>
> >>>>>It doesn't make sense to me to introduce the extensive
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>changes in the
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>ADQL/x
> >>>>>--> 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
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>ADQL, ADQL/s.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>It should be a simple matter to convert a single instance
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>of an ADQL/x
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>query
> >>>>>(ADQ/x) into string form (ADQ/s) using XSL. But, if
> people want to
> >>>>>allow *direct entry* of the string version of ADQL and to
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>parse ADQL/s
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>then we will need some way of generating a new BNF that
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>corresponds to
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>the modified ADQL/x or ADQL/sx; this should be an automated
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>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/
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >>>
> >>>
> >
> >
> >
>
More information about the voql
mailing list