ADQL simplified

[Robert.Power at csiro.au]

Hi Martin,

This was from a while ago, but a couple of queries re
your simplified ADQL:

Why can't we tell what the types are of the columns?
I would have thought this could be determined (from the
registry or if being performed at the data centre, some 
other portal specific way). If this information is 
available, then the type of literals should be preserved 
in the ADQL query and type checking performed.

Similarly for functions. <SUM> is an aggregate function
and so can only be used in this context.

This is assuming that the translation of ADQL to SQL 
should be "smart" (does type checking, syntax checking etc).
If this is not the case, just blindly converts ADQL to SQL,
then if the generated SQL is wrong (due to a problem with 
the original ADQL query) then there is an SQL error reported 
further down the line and user/tool will have to deal 
with this.

I personally prefer a "non-blind" approach where as much 
checking is done when converting the ADQL to SQL, but 
that's just me.

This doesn't mean it can't be trimmed, but I would like the
level of information to be preserved.

Rob

> -----Original Message-----
> From: Martin Hill [mailto:mchill at dial.pipex.com]
> Sent: Saturday, January 17, 2004 4:23 AM
> To: voql at ivoa.net
> Subject: ADQL simplified
> 
> 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