TAP RFC [xtype]

[Markus Demleitner]

Hi Patrick, hi DAL,

On Thu, Sep 17, 2009 at 11:14:22AM -0700, Patrick Dowler wrote:
> 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
Well, according to the serialization rules of VOTables, this is not
comma-delimited but either whitespace-delimited (tabledata encoding)
or whatever else.  But that's a fine point.

> 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).
Argh.  Please don't.  While I think this (a point is just a pair of
numbers) is what things *should* have looked like, this unfortunately
is askew with ADQL that *requires* the coordinate system.  Actually,
ADQL has its own idea of how its geometries should be encoded on
output.  So, now another format.  And what about ADQL CIRCLEs,
POLYGONs, etc?

Also, the coupling of STC info with fields is currently done via
utypes on field, not via xtype.  I happen to believe the referencing
should be the other way round and pointed this out in the VOTable
RFC, but either way: Let's not invent even more ways to specify
things, let's try and come up with one and only one people can
converge to.


> If the latter, is the above correct? What needs to be fixed?
Ideally, drop coordinate system information from ADQL.  Failing that
(and we can't really do this any more at this point), it needs to be
in the output, I think.  And that leaves us with the choice of a
subset of STC-S, ADQL native or yet another new invention.  Given
that choice, I'd go for the subset of STC-S.

> 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)?
TAP is hard enough if it only has to interoperate with TAP services.
Being able to grok anything else shouldn't be a design principle.  If
at all, it would be a nice bonus.

Cheers,

        Markus