TAP RFC [xtype]
patrick.dowler at nrc-cnrc.gc.ca
Thu Sep 17 11:14:22 PDT 2009
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
Is xtype="adql:<adql type>" good enough or should we use xtype="stc:<stc
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)?
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
More information about the dal