RFC for VOTable 1.3

[Pierre Fernique]

Hi Mark,
My contribution for VOTable 1.3.
Cheers
Pierre

*I - General remark*
**
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, no 
IVOA Request For Comments process is required and no IVOA recommendation 
is established. I do not say that the authors and contributors 
(includind myself) of this note did not do a good job but this situation 
generates some problems that we are now facing to.

1) On the client side : my bad experience ! I discovered a few months 
ago that version 1.2 of this note has been replaced by a version 2.0 
unfortunately not compatible with previous version. Concretely, Aladin 
supports the note 1.2

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):
- Most of data providers continue to use COOSYS  - and just ignore the 
VOTable 1.2 REC
- 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 )
- I found (courageously) two providers following the note method : GAVO 
note 2.0, Skybot (vo.imcce.fr) but note 1.x (?)

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

I just cite the last point of 9.2 /"Differences Between Versions 1.2 and 
1.3"/ which illustrates my point :

    /"The representation of STC information in section 3.1 and section
    A.2 has been modified to reflect the recommended//usage from the STC
    in VOTable Note [7]. This usage is recommended even for VOTable 1.2,
    so this/
    /change to the VOTable document represents an update of advice
    rather than a change to the normative part/
    /of the VOTable standard. Additionally, text has been added
    encouraging declaration of the STC metadata/
    /where possible.//"/

*=> May I advocate for following the RFC process without requiring to an 
external note reference* - even if the consensus is difficult to obtain.
And my question : Now, how can we change the situation for cleaning 
VOTable coordinate referencing, and try to redirect our efforts to get 
more convergence.


*II - Reference Implementation:*

 1. After asking André Schaaff, it seems that SAVOT 4.0 is not yet
    supporting VOTable 1.3, only 1.2 (no BINARY2).
 2. Aladin beta 7.547 is now supporting VOTable 1.3 for reading (BINARY2
    + LINK + note 1.2/2.0 "STC in VOTable")
 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)

Is it possible to have somewhere an example of BINARY2 VOTable example ? 
I test generally my reader by using TOPcat writer. But TOPcat is not 
offering yet BINARY2 ouput.

*III - Detail**
***
Page 14 - 4.7 VALUES Element
The example still used a ref="J2000" reference used in old COOSYS 
definition and in note 1.2. But this possibility has been removed in the 
last note (2.0) and prefer to use FIELDref forward referencing method.
I suggest to remove it.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/interop/attachments/20130408/b18d4519/attachment.html>