ADQL simplified

[Martin Hill]

Hi Robert

Hmmm didn't think of that.

At the moment there is not in fact any column-based type information; 
and as you say we could add it, but it's not straightforward.  It means 
that any SQL-like string should include a reference to the 
datacenter/registry entry it is expected to run on, so doing the 
SQL/ADQL -> XML/ADQL translation can be done.  There's a fair amount of 
extra (programming) work doing the transformation & validation, to 
include the lookup, and we need to allow for not finding the registry 
entry.  We could add this as an *extra* validation somewhere...  Or we 
could get datacenters to publish their own ADQL schema to validate 
against.  This datacenter-ADQL would have to be like the ordinary one 
but with the extra type info included - does anyone do/know of anyone 
who does this kind of derivation?  Sounds like it might be useful for 
other things.

(In fact at the moment the type is usually derived from the way the 
number is specified: 2 is an integer, 2.0 is a real, '2' is a string).

As for functions, etc, where we want to specify that a value must be a 
number, we can do this in the schema so that the values are restricted. 
  So a schema might include (I think, without reference book to hand):

   <xs:element name="SIN" type="xs:real"/>

to allow us a simpler document element like this, that only takes real 
numbers as arguments:

   <SIN>2.234</SIN>

Which satisfies my usual criteria: it's simple to read and write, and 
easy to decode when parsed!

Cheers,

Martin




Robert.Power at csiro.au wrote:
> 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
> 
>