TAP RFC [xtype]

[Patrick Dowler]

On Monday 14 September 2009 02:00:09 Keith Noddle wrote:
> In consultation with Christophe, I therefore propose that we extend the
> TAP RFC to 25th September to allow the above details to come together.

We concluded in emails in the early last spring and in the spring interop that 
columns in VOTables uploaded to or resulting from TAP required a consistent 
bi-directional mapping of datatypes. 

VODataService allows column datatype to explicitly specified from different 
specs: namely votable and adql. The xtype attribute was added to VOTable (field 
and param) so that VOTables could be as explicit when relevant datatypes went 
beyond the primtiive types in VOTable.

The current spec says that xtype values are the same as those allowed in 
VODataService: adql:TIMESTAMP, adql:POINT, adql:REGION and the meanings of 
these types are as specified in the ADQL spec. This approach is very explicit, 
would allow query results from one service to be uploaded to another, and 
extends pretty well to other query languages that may also define types.

VOTable describes two special xtype values (iso8601 and STC-S) but the latter 
does not distinguish between point and region (which adql does), so this is 
not sufficient for TAP.

To improve interoperability with other (non-TAP) services, it would be nice to 
use a neutral set of types. Since we will also likely extend and/or use energy 
and redshift, STC seems the obvious choice. To that end, I came up with this 
by drawing class names from the STC model.

TIMESTAMP : xtype="stc:ISOTime"

For timestamp, the content is the usual ISO8601 timestamp string.

REGION : xtype="stc:Region" 

For region, the content is an STC-S REGION string.

POINT : xtype="stc:Position2D"  datatype="double"  arraysize="2"

For point, the content is the usual comma-delimited pair of numeric values, 
and use a ref="something" to connect it to a coordinate system

Caveats: To be correct, one may have to use something longer and more like 
utypes than just the simple class names I have used above (TBD).

The use of point above is for databases that really expose geometry types. For 
those with simple scalar columns for coordinates, those would be done with two 
columns (FIELDs); both columns would ref="something" to specify the same 
coordinate system, and the xtype would be an extension of the above to signify 
which is longitude and which is latitude, eg 

name="ra" xtype="stc:Position2D.C1"  datatype="double" 
name="dec" xtype="stc:Position2D.C2"  datatype="double"

Caveta: I don't know if the .C1 is correct, or if it should be / or some other 
connector (TBD).

-----------
Is xtype="adql:<adql type>" good enough or should we use xtype="stc:<stc 
type"> instead? 

Note: We could use xtype="adql:POINT" datatype="double"  arraysize="2" to 
specify the value encoding nicely.

If the latter, is the above correct? What needs to be fixed?

What is more improtant: consistency of TAP VOTable headers with VODataService 
or more flexible interoperability with other kinds of services (specifically, 
without having to manipulate the table)?


-- 

Patrick Dowler
Tel/Tél: (250) 363-0044
Canadian Astronomy Data Centre
National Research Council Canada
5071 West Saanich Road
Victoria, BC V9E 2M7

Centre canadien de donnees astronomiques
Conseil national de recherches Canada
5071, chemin West Saanich
Victoria (C.-B.) V9E 2M7