VODataService becoming WD, then PR

[Patrick Dowler]

I will say my bit on the DAL list since this is wrt the TAP spec:

On 2008-11-19 02:10:34 Gerard wrote:
> Irrespective of this, according to 3.1.1.2 in
> http://www.ivoa.net/internal/IVOA/TableAccess/TAP-v0.3.pdf, TAP also has a
> mode allowing ("MAY") pass-through of native SQL, though it seems it has
> not been worked out in detail yet.
> Taking this option seriously might have some impact on the metadata
> specification.
> For example one might then want to include a "nativeSQLType" for the column
> metadata.
> ALso I suppose the TAP service as a whole could(should) specify the
> database vendor.

The idea behind "native SQL" in TAP is that the caller knows the DB schema 
already (out of band) and wants to tell the service how to interpret the 
QUERY parameter. That is, tell it to NOT process the query (from ADQL -> 
SQL).

While I am not that excited about this feature as it is explicitly 
non-portable and non-standard, it is one that some services may want to 
provide to power-users who need access to something not in ADQL. It is not 
that we are designing this so much as just saying "if you want to do this, do 
it this way". Now, any one service could do this anyway and it would not make 
them non-compliant. However, by adding it to the TAP spec (even loosely) we 
are reserving some value of the LANG parameter that goes with QUERY so that 
in future any change/addition to TAP will not step on custom extensions like 
this. The alternative is that someone might make use of a custom param 
(NATIVE=true) and then would complain and/or have to do work if some future 
version of TAP wanted to define that parameter.

So, we just want to reserve a value for LANG, recommend (strongly) that people 
use that for native SQL. After that, this is for power-users who know the 
schema, so we can (should) stop there... and by stop there I mean stick with 
only the VOTable data types. This is really to allow people to use features 
of the DB directly (eg CUBE and ROLLUP in DB2, table-valued functions, and 
stuff that is not part of ADQL). The service still has to return it in 
VOTable, so it has to coerce the values into VOTable datatypes.

-- 

Patrick Dowler
Tel/Tél: (250) 363-6914                  | fax/télécopieur: (250) 363-0045
Canadian Astronomy Data Centre   | Centre canadien de donnees astronomiques
National Research Council Canada | Conseil national de recherches Canada
Government of Canada                  | Gouvernement du Canada
5071 West Saanich Road               | 5071, chemin West Saanich
Victoria, BC                                  | Victoria (C.-B.)