ADQL v0.7.3

[Tony Linde]

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

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