The case for XML ADQL

[Martin Hill]

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' 
of it.

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:

    <DatacenterFunction name="HtmSearch">
        <Parameter>HtmIdenitfier</Parameter>
    </DatacenterFunction>

or by creating a datacenter-specific ADQL schema that extends the standard one.

Cheers,

Martin

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

-- 
Martin Hill
Software Engineer
AstroGrid @ ROE
Tel: +44 7901 55 24 66
www.astrogrid.org