Standard | Release Date |
---|---|
VOTable 1.3 | 20 September 2013 |
VOTable 1.2 | 30 November 2009 |
VOTable 1.1 | 11 August 2004 |
Consider for future version | Reference | Earliest Version | Notes |
---|---|---|---|
Port the VOTable source to ivoatex. | 1.5 | ||
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. | 1.5 | ||
Add optional "refposition" attribute to COOSYS. Or maybe "refposition" should be required? |
1.5 (or 2.0 refposition is required) | ||
Remove mention of UType in section 1.4, as it is lacking a standard. | 1.5 | ||
Sec. 4.6: Remove paragraph "In order to avoid name collisions..." | 1.5 | ||
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. |
Suggestion by Tom Donaldson | 1.5 | |
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 |
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". |
?? | ||
Add a table of definitions for allowed COOSYS "system" attribute values. | 1.4 RFC Comment | 1.5 | If uncontroversial, could be done during 1.4 RFC period. |
Make COOSYS and TIMESYS more consistent:
|
1.4 RFC Comment as well as previous discussions | 2.0 | The only reason these weren't done for 1.4 were to preserve backward compatibility. |
The example in 3.7, where a LINK element is used to reference a SKOS concept, is using an outdated and abandoned vocabulary (on purl.org). Update this when a new-style physical quantities is ready (or just remove the outdated reference). | 1.4 RFC Comment | 1.5 |