The case for XML ADQL

[Wil O'Mullane]

The SKyNode Spec deals with this - why overload ADQL.
The DataCenter should publish available functions in standard manner.
Similiar to the way it publishes tables,cols,ucds etc..

In you previous mail you have slipped an 'into' into ADQL. Now that is
not in the spec which is on the table so far. Now SADQL departs from 
the prose specification. If we want 'into' in our semantic at this stage 
then we need to revise the specification also.

This is a seperate issue to SADQL vs ADQL xml syntax.

wil


On Fri, Feb 06, 2004 at 01:47:08PM +0000, Martin Hill wrote:
> 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