The case for XML ADQL

[Tony Linde]

While I think I've been the strongest proponent of making schemas complex
(and so developer's lives difficult) so that the user's lives can be made
easy (ask Ray :) ), I also think we need to make sure that it is relatively
straight-forward to turn an adql query into a sql query as this is going to
be required at every data centre. 

An xml-form of adql is going to be much easier to translate into the end
sql. If the people at all the data centres have to write adql/text parsers
in order to translate queries into their own flavour of sql (and, as Ray
says, which matches their own particular implementation), then the VO is not
going to spread too quickly.

But Jim is also right that some users will want to type in a text form of
query and have it automatically converted to the xml-form before it is sent
out to chosen data centres.

So we need both forms of adql: adql/text and adql/xml. But the standard form
of query transmission should be adql/xml and for this reason it should be
our priority.

Cheers,
Tony. 

> -----Original Message-----
> From: owner-voql at eso.org [mailto:owner-voql at eso.org] On 
> Behalf Of Jim Gray
> Sent: 05 February 2004 08:50
> To: Ray Plante; voql at ivoa.net
> Subject: RE: The case for XML ADQL 
> 
> 
> Computers are good at parsing 
> People are good at other things. 
> Making ADQL convenient for computers seems the wrong optimization. 
> 
> 
> 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 Ray Plante
> Sent: Wednesday, February 04, 2004 10:39 PM
> To: voql at ivoa.net
> Subject: The case for XML ADQL 
> 
> As one of the loud voices insisting on having an XML version 
> of ADQL, I feel I should put in my 2c.  As Wil, Tony, and 
> others have mentioned, XML is easier to parse than SQL.  This 
> begs the question, why would you want to parse the query.  
> Similarly, by not having an XML version suggests that there 
> is no reason to parse the query.  
> 
> In my mind, the need to parse the query is clear.  The first reason is
> obvious:  there is no universally supported standard SQL--all 
> vendors differ in small annoying ways.  However, I think 
> there is a more important issue independant of the SQL 
> standard:  I believe it will be quite common for the tables 
> that are exposed to the outside will differ substantially 
> from what is actually on disk.  The differences may be as 
> simple as the names used for the columns to hiding the 
> complexity of highly normalized tables to integration with 
> alternate database technologies.  While some differences 
> might be handle via database VIEWs;  but some will not be so 
> simple.  This is less likely to apply to your basic object 
> catalog that are typically flat and simple; however, 
> observation archives usually manage more a more complex data 
> model that is easily by todays browser-based interfaces.  
> Only by allowing pre-database parsing affords the flexibility 
> to adapt to the variety of data models that I suspect exists 
> out there.
> 
> BTW, I believe that handling something as complex as ADQL by 
> deserializing it into Java objects as is done autmatically 
> with WS toolkits and packages like JAXB/Castor is a recipe 
> for heartbreak. (People have complained about the chain of 
> function calls necessary to navigate VOResource--it's the 
> same problem.)  Learn XSL and use it to convert it to the SQL 
> (or whatever else).
> 
> cheers,
> Ray
> 
> 
>