ADQL v0.7.3

[Vivek Haridas]

The precedence section of the .ycc file takes care of LEFT/RIGHT
association in such cases and also helps in putting precedence of certain
operators over others.

So my opinion is that "a AND b AND c AND d"
is actually 3 AND operations with two parameters each
and not just one AND with four parameters.

with Best Regards,
Vivek



On Mon, 1 Mar 2004, 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.
>
> 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/
> > >
> >
>