ADQL simplified

[Wil O'Mullane]

My understanding of what was wanted from ADQL was a Parse tree for
computers to work with. Not something human readable.
We took a BNF for SQL changed it a little and fed it through
Visual Parse to generate a Parser for the language.
The then took classes from the parser and generated XSD for those.
SO it is a completely automatic process which leaves in some redundancy
but does make for much consistency..

Now that is assuming we wanted a parse tree..

wil

On Fri, Jan 16, 2004 at 05:23:22PM +0000, Martin Hill wrote:
> I'm working on a simpler ADQL that is less verbose and so easier for humans and 
> tools to process.  However I wanted to check first, is there a particular reason 
>   why values are so fully (and somewhat redundantly) specified?  eg 
> <Value><NumberLiteral><IntNum><Value>3</Value...etc?  Was it just to specify the 
> values fully?
> 
> As far as I can tell, specifying type (ie integer, string or real) offers no 
> extra checking in practice, as we can't tell what types the columns are that are 
> being compared with (and it would be hard to validate anyway).  Also, it doesn't 
> match the way that numbers are used in the Region schema.  And we lose this 
> information when we convert backwards and forwards to the SQL-like string format 
> - or is this no longer considered important?
> 
> Similarly with the functions - we have eg <Function><AggregateFunction><SUM> 
> rather than just <Function><SUM> (or indeed <SUM>)
> 
> Would anyone have any objections to removing these redundant nested tags?  Or 
> point out which wrong end of the stick I'm holding?
> 
> Cheers,
> 
> Martin
> 
> 
> 
> -- 
> Software Engineer
> AstroGrid @ ROE
> Tel: +44 7901 55 24 66
> www.astrogrid.org
>