VODataService becoming WD, then PR

[Gerard]

Pat wrote (amongst others)

> 
> > 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.
Not trying to be pedantic, but conversion from what to what? Since ADQL does
not specify data types, and TAP is not adding them, there is nothing to
convert from. Is there? 

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

> ...

> Anyway, having more richness of types in SQL is of little 
> value when results have to be converted to types allowed by VOTable.
> 
I do not agree. There is value in having more richness of types at the level
of the TAP metadata specification. After all that specification governs what
ADQL queries I may write. 

Though I can understand that something like VOTable will carry the result of
an ADQL query, I don't understand why the VOTable specification would also
govern the TAP metadata description.
VOTable was not designed to do so, otherwise it would have had a richer type
system from the beginning. 
Apart from region, VOTable does not have date or time types for example. But
it is clearly (isn't it?) useful to know that a column is a date when I
write a query against it, even if afterwards it is serialised to a string
(well, char*) in VOTable.
I find it somewhat perplexing that in effect a 30 year old standard (FITS)
is indirecty governing how we describe relational databases today.

Gerard