TAP/VOSI 1.1: required type system?
Markus Demleitner
msdemlei at ari.uni-heidelberg.de
Wed Dec 16 12:38:25 CET 2015
Hi,
While playing with a table that actually has a region-valued column
(in case you're curious: antares10.data on ivo://org.gavo.dc/tap), I
was horrified to see it is shown in TOPCAT's metadata browser as
being of type char[*].
The reason for that is that that's what I'm saying on the VOSI
endpoint:
<column>
<name>origin_est</name>
<description>A circle around the most likely position
with ang_error radius (for convenient matching)</description>
<ucd>obs.field</ucd>
<dataType arraysize="*" xsi:type="vs:VOTableType">char</dataType>
<flag>nullable</flag>
</column>
Background: VODataService 1.1 defines several type systems --
essentially, the inheritance tree looks like this:
DataType
|
+--- SimpleDataType (integer, real, complex, boolean, char, string)
|
|
+--- TableDataType
|
+--- TAPType
|
+--- VOTableType
and VOTableType doesn't really contain the VOTable's xtype (we could
probably hack it through extendedSchema and extendedType, but I'd
rather wait how bad the xtype thing will really turn out).
When writing DaCHS' VOSI interface, I figured that since I'm usually
producing VOTables, writing my types as VOTableTypes would be the
most sensible thing to do.
Turns out it's not.
Leaving aside my general skepticism towards stealthily expanding
VOTable's type system with xtype, which I believe will keep causing
lots of headache: I believe to keep clients and users sane, we should
in TAP 1.1 (and perhaps VOSI 1.1) say that in the table metadata of
TAP endpoints, services really-really-should use the vs:TAPType type
system (which probably needs to be fixed soon to include CIRCLE and
POLYGON), and announce that in the next major version, that will
become a must.
Thoughts?
Cheers,
Markus
More information about the dal
mailing list