VODataService becoming WD, then PR

[Patrick Dowler]

On 2008-11-19 11:05:16 glemson wrote:
> HI Pat
> Thanks for your reply, it was not clear to me from the current draft how to
> interpret the native SL. Your explanation does take this away as a reason
> to have SQL data types in the metadat.
>
> It leaves my questions about ADQL (non-)use of data types.
> What was the reason that SQL92's <data type> was left out of ADQL?
> Same for CAST and create table statements.
> Is there the possibility these might one time be introduced?

ADQL only supports SELECT (without INTO) in the first version, so it is 
read-only. It is possible that a future version could include othr kinds of 
statements, but with SELECT covering > 95% of the uses it was not worth the 
wait. As for data types, they are included as reserved words and in future we 
could more explicitly include types/casts/etc in the language, but you do not 
need that for most uses (well, cast and/or non-implicit type conversion 
maybe, but then you are also well past the line where a generic/portable QL 
is going to cut it). 

> Related, are the VOTable datatypes rich enough to represent all SQL
> datatypes (I have not done the comparison, has anyone)?

No, I think VOTable is a subset and service specifications will have to say 
how the conversion (cast) is done, where necessary.

An obvious example is that ADQL makes it possible to have columns of
type "region" and return them in a select. The TAP spec will have to say that  
the VOTable FIELD will be datatype="char" and arraysize-"*" and the content 
will be encoded (STC/S encoding) as a string. I do not know off hand if the 
FIELD allows one to say that the value is encoded; if not, then specs will 
likely have to chose a single encoding. I would assume the STC region 
returned in a VOTable has been dealt with in the footprint services as that 
is the primary function of those services... 

I think encoding of some SQL types into datatype="char" and arraysize-"*" is 
always going to be necessary because the alternative is to continually (well, 
multiple times anyway) add datatypes to the VOTable spec. I just don't think 
that is desireable or practical. I know the DM group has also wored out how 
to serialize STC region into  a VOTable, but in TAP (ADQL specifically) the 
number of columns in the VOTable should match those in the query, so I don't 
think flattening the region into multiple (scalar) columns is a good or 
viable option, and I don't really think it adds much value to do so... but I 
have not looked at that closely enough (yet) to know.

Anyway, having more richness of types in SQL is of little value when results 
have to be converted to types allowed by VOTable.

-- 

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.)