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