Martin,
I'm making an analogy with SQL:
select <column> from <tables> where <expressions involving columns>
By specifying a particular table(s), the types of the columns can be determined either locally at the portal or via the registry.
When you mention the query will " ... include a reference to the datacenter/registry entry it is expected to run on ", I'm assuming that since the ADQL will reference a particular table (VOResource) then its description should be same regardless at which data centre it as at (the same table might be replicated at various data centres).
So the column based type information need not be included in the ADQL itself, but it can be determined during query processing (ADQL->SQL).
Perhaps this is too much effort and a barrier to entry to be required for all portal developers, but it could be an extra capability.
Rob
> -----Original Message-----
> From: Martin Hill [mailto:mchill-at-dial.pipex.com]
> Sent: Tuesday, January 27, 2004 8:46 PM
> To: Robert.Power-at-csiro.au
> Cc: voql-at-ivoa.net
> Subject: Re: ADQL simplified
>
> 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
> >
> >
Received on 2004-01-27Z23:56:20