VODataService becoming WD, then PR

[Arnold Rots]

The encoding of regions has also come up in a different context:
footprints.
I prepared some examples at:
  http://hea-www.harvard.edu/~arots/nvometa/STC/#regions

  - Arnold

Gerard wrote:
> 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
> 
> 
--------------------------------------------------------------------------
Arnold H. Rots                                Chandra X-ray Science Center
Smithsonian Astrophysical Observatory                tel:  +1 617 496 7701
60 Garden Street, MS 67                              fax:  +1 617 495 7356
Cambridge, MA 02138                             arots at head.cfa.harvard.edu
USA                                     http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------