RFC for VOTable 1.3

[Markus Demleitner]

Hi,

Two points in reply to Pierre --

On Mon, Apr 08, 2013 at 12:09:08PM +0200, Pierre Fernique wrote:

> 2) On the data provider side : since 4 years of VOTable 1.2 REC,
> there are more and more divergence VOTable coordinate system
> reference codings (based on my experience):
[...]
> - Some data providers have removed COOSYS, but without replacing it
> by the note method (1.2 nor 2.0) (ex: dc.zah.uni-heidelberg.de,
> adsabs.harvard.edu, wfaudata.roe.ac.uk )
[...]
> 3. I was not able to check if TAP GAVO is VOTable 1.3 compliante
>    (provides BINARY, no BINARY2, and without note "STC in VOTable"
>    usage - ex : hipparcos)

Since it may be relevant as to the implementations requirement of a
REC: Where we (dc.zah.uni-heidelberg.de) give STC metadata, we give
them in 2.0 style.  For our mirror of the original Hipparcos catalog,
STC metadata happened to be missing in our internal metadata description.
That's fixed now, and hence the declarations are there in 2.0 style,
as they are for many other data collections on our site.

As to BINARY2, we do support it and the VOSI capability record says
so (it's available with FORMAT either
application/x-votable+xml;serialization=binary2 or votable/b2).


Although it's somewhat off topic, let me quickly note:

> The last VOTable release from 1.1 to 1.2 deprecated the usage of
> COOSYS and encouraged to follow the IVOA note ([7] Referencing STC in
> VOTable v2.0). Same for VOTable 1.3.
> Concretely, the VOTable 1.2 & 1.3 just provides an example (3.1
> Example p9 + A.2) which illustrates the usage of coordinate metadata
> description following one possibility of the cited note (GROUP +
> PARAM + URI + FIELDref).
> 
> This note is now evolving independently of VOTable. As it is a note,

This is indeed unfortunate at should be changed on a medium time
scale.  However, if we tackle this, we will certainly want to
overhaul the STC data model.  Judging from previous efforts, I would
expect a REC-level document on declaring STC metadata will not be
immediately forthcoming...

> In the near future, "utype tiger" team will propably propose another
> way to describe coordinate meta data in accordance to a new utype
> usage. I suppose that the note will certainly evolve again... but
> with no more RFC process...

...and hence I'd doubt this is going to be the *near* future.  This
means that there's no excuse not to provide STC metadata in your
VOTables now, preferably in note 2.0 style.  Also, whatever form STC
metadata might have after a utypes REC, it will be not terribly far
from the Note 2.0 style, so your work won't be wasted even when a
REC-level STC metadata specification will appear.

tl;dr: save tomorrow's papers, mark up your STC metadata today.

Cheers,

         Markus