VOTable is a standard for the interchange of data represented as a set of tables, and includes both table metadata and the data itself.

The Application Working Group assumed responsibility for VOTable with version 1.3 when the VOTable Working Group was retired.

Recommendation History

See IVOA Document Versions for the official list of all IVOA documents and versions.

Standard Release Date
VOTable 1.3 20 September 2013
VOTable 1.2 30 November 2009
VOTable 1.1 11 August 2004

In Progress


We are currently working on VOTable 1.4, which is a backward-compatible revision to support a new TIMESYS element and other miscellaneous cleanup. See also the original note: A Proposal for a TIMESYS Element in VOTable

Latest Draft

VOTable 1.4 (Working Draft)

Please add comments, concerns, and implementation notes to this RFC page: VOTable 1.4 Request For Comments

Past Drafts

See: VOTable 1.4 Working Draft Notes


Consider for future version ReferenceSorted ascending Major/Minor Notes

The current guidance on versioning is that the namespace URI should remain constant for all minor revs of a major version. That's fine, but I think the added feature of having that URI be a URL to the latest schema version is more confusing than convenient.

The biggest problem for VOTable is that the schema now has to allow multiple version attributes (e.g., 1.3 and 1.4) to support backward compatibility, while at the same time allowing 1.4-only features like TIMESYS. This makes the schema somewhat inaccurate as it allows version="1.3" and TIMESYS in the same document.

I would be happy to remove the convenience of having the namespace URI point to the latest schema. For VOTable writers that want to specify the schema (not required), they may as well point to the specific version. They know the version since they already must specify the version="1.x" attribute.

That discussion is outside the scope of VOTable itself, so if that remains unchanged, I propose that we recommend using the specific version schema URL instead of the namespace URI if referencing the schema.

DataLink recommends using a "content" parameter. Consider mentioning it in sec. 8 (MIME types) to avoid other standards reinventing the same thing with a different name. email Minor  
Add optional "origin" or "refposition" attribute to COOSYS email Minor  
Port the VOTable source to ivoatex. email Minor Markus has valiantly volunteered.
Remove mention of UType in section 1.4, as it is lacking a standard. email Minor  
Sec. 4.6: Remove paragraph "In order to avoid name collisions..." email Minor  

delaying refposition attribute in COOSYS. I understood that Arnold has strong arguments that when we have COOSYS and TIMESYS they would have to share the same refposition which is something will should be explained clearly in the text in case this COOSYS addition would have been validated. I also understand that as a matter of consequence the refposition in TIMESYS is also valid for an associated COOSYS. But in case we only have COOSYS, this refposition is strongly missing. So if we delay that to 1.5 we should at least reinforce he need for this change in the Notes.


People here at CDS have been playing around the TIMESYS with example taken in VizieR. This really shows that in many cases a "double"-valued (or more) ref should be a great help. The solution could be to change the definition of ref in VOTable schema from IDref to IDrefs. This was discussed at the time of the TIMESYS note was made public and Mark T said it could have consequences to be addressed. Such a mechanism could also enter in competition with "ref" set on GROUPS. So I agree this may be a too long discussion. But this should be set in the Notes as something to tackle in version 1.5


decimal years representations in 3.5 : usage of besselian or julian years for timestamps apart from making timeorigin un-useful (and then forbidden) also implies some inference on the timescale used (see the TIME WCS paper for references and discussion). I suggest to add the the following sentence at the end of "timeorigin" explanation: "When using calendar epochs written in yr or Ba, note that conventionally Julian years are tied to the TDB timescale and Besselian years to ET (written here as TT) (Rots and Bunclark et al., 2015)." By the way, on a related topic I discover that in 3.4 COOSYS, we don't explicitly constrain the representation of time in equinox and epoch attributes. This however clear in the xml schema. I suggest adding after "... the epoch of the positions if necessary", the following sentence: " Both equinox and epoch MUST be expressed in the Julian or Besselian calendar".


Historical Information

Topic revision: r2 - 2019-06-03 - TomDonaldson
This site is powered by the TWiki collaboration platformCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback