The case for building ADQL from a SQL core.

[Jim Gray]

I  agree:  "there's no real difference between extending ADQL/string and
ADQL/xml." 
   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
complex expression
 
   SELECT <select list>
   INTO <table name>
   FROM <from expression>
   WHERE <predicate>
   GROUP BY <group by list>
   HAVING <predicate>
   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. 

   

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

-----Original Message-----
From: owner-voql at eso.org [mailto:owner-voql at eso.org] On Behalf Of Martin
Hill
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
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