The case for building ADQL from a SQL core.
gray at microsoft.com
Fri Feb 6 07:08:28 PST 2004
I agree: "there's no real difference between extending ADQL/string and
In both cases, you start from zero and have to write a man-page for
every feature (since you start with the empty set and build ADQL)
The point is that there is a huge difference between
subsetting SQL and
creating a new core language from scratch.
In the subsetting approach you hijack the years of language design and
skills of the SQL folks.
In the creating a new core lanugage you go it alone and have to do that
design and write those man pages yourself.
That is a BIG difference.
The current efforts been defining language syntax (in xml) and leaving
the semantics to the reader.
The semantics are the hard part.
Hijacking someone else's semantics is a lot easier.
So, there is a BIG difference between the two approaches.
The SQL first approch can just hijack the semantics for this rather
SELECT <select list>
INTO <table name>
FROM <from expression>
GROUP BY <group by list>
ORDER BY <order list>
One has to modify the naming and explain about MyDB and define the
non-standard functions, but that is easy compared to explaining the
semantics of this beast.
Microsoft Research, Suite 1690, 455 Market, SF CA 94105,
tel: 415 778 8222 fax: 425 706 7329
Gray at Microsoft.com http://research.Microsoft.com/~gray
From: owner-voql at eso.org [mailto:owner-voql at eso.org] On Behalf Of Martin
Sent: Friday, February 06, 2004 5:47 AM
To: Clive Page
Cc: voql at ivoa.net
Subject: Re: The case for XML ADQL
In fact there's no real difference between extending ADQL/string and
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
or by creating a datacenter-specific ADQL schema that extends the
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.
AstroGrid @ ROE
Tel: +44 7901 55 24 66
More information about the voql