VODataService 1.3 PR - deprecation of TAPType

[Markus Demleitner]

Hi Paul,

On Thu, Jul 23, 2026 at 11:21:48AM +0000, Paul Harrison wrote:
> duplication (with different names) of the “obvious” primitive types
> (int, float etc.) but what about the other more specialist TAP
> types like TIMESTAMP and POINT - what are providers supposed to do
> if their TAP service exposes such columns - surely there should be
> some attempt to unify all VOTableType and TAPType into a single
> type.

First off, on the "why": *if* there's ever a case for discovery by
type, things become ugly if there is more than one vocabulary for
types.  Also, of course, clients that want to reason about types they
get from the tables endpoint shouldn't have to understand to
different type systems. We've done the move to VOTable types in
TAP_SCHEMA, too, for just same reason: servers must map to them
anyway, so there's no good reason to even expose internal choices.

Then, about the extended types: In VOTable, xtype was chosen to
declare them, and DALI has the canonical list of them.

This is why we say, on p. 46:

  When the actual column type is not well matched to a VOTable data
  type, authors are encouraged to use the extendedType attribute to
  refer to a more specific type. This will usually be a VOTable xtype
  as defined by DALI (Dowler and Demleitner et al., 2017).

I wish we could make this a bit more normative, but regrettably there
still are really odd TAP schemas out in the wild, and as long as they
are there, we can't really outlaw them.

Thanks,

             Markus