ADQL v0.7.3
Ed Shaya
Edward.J.Shaya.1 at gsfc.nasa.gov
Tue Mar 2 07:35:46 PST 2004
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