The case for XML ADQL
mchill at dial.pipex.com
Fri Feb 6 05:47:08 PST 2004
In fact there's no real difference between extending ADQL/string and ADQL/xml.
We can't in practice allow ADQL/string to pass through 'blind' in general for
security reasons, so ADQL/string parsers will need to be updated to provide for
new functions. Anyway there will usually need to be a translation layer to get
to the local SQL form, and ADQL/XML gives us the one->many rather than
many->many combinations we need.
We *do* need to ensure scope for adding new functions, but this has to be
treated carefully; ADQL is meant to be a *standard* query language that we can
apply across a range of datacenters. If a particular datacenter implements a
particular new function, but other datacenters do not, we lose the 'generality'
So I suggest that the datacenter-specific functions do not need to be built into
the ADQL language itself, but either inserted as an unchecked element, eg:
or by creating a datacenter-specific ADQL schema that extends the standard one.
Clive Page wrote:
> On Thu, 5 Feb 2004, Tony Linde wrote:
>>Anyone who wants to provide a text input service will have to write a parser
>>that translates from the text form into the standard xml form.
> I think it will be essential to have converters in both directions between
> ADQL/text (alias SkyQL) and ADQL/XML. We have already found that it is
> exceedingly difficult to test software which requires fully formed XML as
> its input, so the testers need to be able to input ADQL/text. I think
> power users who are already familiar with SQL will want to be able to
> continue using it (or something very similar) - they will not take kindly
> to instructions to learn ADQL/XML. Thirdly, the ADQL/text form has very
> limited extensibility: if some backend can provide additional facilities
> such as stored procedures/user-defined functions, then these would be
> unusable from ADQL/XML until the parsers have been modified and tested,
> but a pass-through of ADQL/text would be able to use these extensions
> immediately, and they might (if suitable) be incorporated into the
> standard at some future date. A living language needs a simple route for
AstroGrid @ ROE
Tel: +44 7901 55 24 66
More information about the voql