Re: ADQL simplified

Thanks for the history! I remember ADQL/XML was originally going to be a machine-only language. However now that we're using it, we're finding that in practice it's useful to work with it directly as well. Partly it is just that while testing and prototyping it's easier to work with directly as the ADQL/String -> ADQL/XML translations are not wholly reliable yet*. But also I think there may be a human place for it, as it can be validated directly (so errors can be reported meaningfully to the user) and we can write tools more easily I think to handle the XML structure than the SQL one.

But yes we definitely need to make sure ADQL/XML is still defined so that the maximum number of XML tools can be used to process/generate/edit it.

Cheers,

Martin

*How do the ADQL String->XML translators make type decisions with the existing structure - eg how does a statement like 'WHERE X > 2' get translated when '2' might be a real or integer, or even a string...?

Quoting Wil O'Mullane <womullan-at-skysrv.pha.jhu.edu>:

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

-- 
Martin Hill
07901 55 24 66
www.mchill.net