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
>
Received on 2004-01-16Z19:32:22