VODataService 1.3 PR - deprecation of TAPType

[Paul Harrison]

> On 23 Jul 2026, at 12:54, Markus Demleitner via registry <registry at ivoa.net> wrote:
> 
>  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.

In my VO-DML model to automatically generated TAP service view of the world then the choice is
made at the time of the model creation - if you make an attribute a Point type,  then it will become a Point type
in the database column, with all the advantages that has. The most natural thing to do is to expose this information to
the user - which can be done via the xtype - rather than have some extra layer of configuration of the TAP service, to “hide” this.

> 
> 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.
> 

I would like it to be more normative from now on - clients need to understand that xtype=“point” always means that…

It would be good in the deprecation documentation to have direct references to the text that you have picked out, as you have to go from VODataService -> TAP -> VOTable -> VOSI at the moment to discover it.

Regards,
	Paul.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2893 bytes
Desc: not available
URL: <http://mail.ivoa.net/pipermail/registry/attachments/20260723/2cfb4977/attachment-0001.p7s>