Difference: VOTable15RFC (17 vs. 18)

VOTable 1.5 Proposed Recommendation: Request for Comments

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

Summary

Latest Draft: VOTable 1.5 (Proposed Recommendation)

The main purpose of VOTable 1.5 is to support refposition attribute analogous to TIMESYS.

VOTable 1.5 is a backward-compatible revision.

The other main differences between version 1.5 of VOTable and the preceding version 1.4 are:

To Do Upon Approval, Prior to Upload

• Change version attribute in schema to "1.5"
• In the document, set the \ivoatype to "IVOA Recommendation" and set the status text according to the official wording is in DocStd.

My advice: Follow the submission checklist in ivoatexdoc: https://ivoa.net/documents/Notes/IVOATexDoc/20230627/NOTE-ivoatexDoc-1.4-20230627.html#tth_sEc3.12 (or, even better, the checklist from a current checkout of git@github.com:ivoa-std/ivoatexDoc.git) -- MarkusDemleitner - 2024-04-30

Future

The VOTable GitHub Issues page contains a list of issues and proposed future enhancements. It is the main mechanism for contributing to the standard.

Reference Interoperable Implementations

DaCHS produces COOSYS refposition in TAP results from the gaia.dr3lite table in the GAVO Data Center TAP service which can be read by the latest versions of STILTS and TOPCAT. For example:

• STILTS shows the metadata from the GAVO TAP results:
  • stilts tapquery tapurl=http://dc.g-vo.org/tap sync=true adql='select top 1 * from gaia.dr3lite' ocmd=meta

• STILTS rewrites the VOTable from the GAVO TAP results, including the COOSYS refposition:
  • stilts tapquery tapurl=http://dc.g-vo.org/tap sync=true adql='select top 1 * from gaia.dr3lite' ofmt='votable(version=V15)' | grep COOSYS

• TOPCAT's Columns Window shows that same metadata for those same GAVO TAP results.

Implementations Validators

• The latest version of STILTS (v3.4-10) validates VOTable 1.5 with the following command:
• stilts votlint my_votable_file.xml

• The validates VOTable 1.5 by following these instructions:
  • Click on Load for VOTable.
  • In the empty text box below "URL of the service to validate:", enter the URL of a VOTable to validate.

Comments from the IVOA Community during RFC/TCG review period: 2024-April-25 - 2024-June-06

The comments from the TCG members during the RFC/TCG review should be included in the next section.

In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment.

Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this document

• Sample comment by WikiName
  • Response (by WikiName)

Comments from Markus Demleitner, 2024-04-30

I have skimmed the diffs from commit c6575888 on (hint: git diff -b is a godsend for that). I have found some minor style issues, for which I have created PR #61 (https://github.com/ivoa-std/VOTable/pull/61). Feel free to discard this if you think it does not improve presentatin.

I have one actual question: What about getting MIN/MAX parsing fixed in astropy? This would actually be my favourite reference implementation. Is anyone on it? I'm totally not wild on doing this myself (too much tooling in astropy for my taste), but if there are no other volunteers, I might be talked into putting it in.

-- MarkusDemleitner - 2024-04-30

This is a bug to be fixed later -- AdrianDamian - 2024-06-12

Comment from L.Michel, 2024-05-02

Is there a way to connect the XSD with the IVOA vocabulary in order to make the system attribute in COOSYS rule machine-readable.
This would be very usefull in other contexts (Registry, DM)

-- LaurentMichel - 2024-05-02

In short: We can't, because XML Schema does not understand RDF at all, let alone the way we are using it.
There is a longer answer: We could define an IVOA-controlled schema extension, where a short piece of software would take a schema "template" and fill out enumerations from vocabularies. Then this thing could update the schemas when the vocabularies change.
There is a lot to be said for that. But there is the important counter argument that the schema files would change "on the fly". Whether that is something we want requires a lot of thought.
On the other hand, this is not really much of a practical problem; VOTable validators need to check so much more than the XSD compliance, starting with whether the data content somewhat matches the FIELD-s, that doing the vocabulary validation externally is a relatively minor matter. -- MarkusDemleitner - 2024-06-12

Comments from TCG members during the RFC/TCG Review Period: 2024-April-25 - 2024-June-06

WG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment.

IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.

TCG Chair & Vice Chair

Applications Working Group

Data Access Layer Working Group

It seems OK.

The clarification about the COOSYS elements, especially with the use of an IVOA vocabulary is very appreciated. It will certainly help VOTable providers and validators. Similarly, mentioning MIVOT in VOTable will also be useful to VOTable providers to be aware of a possibility to bridge data with data models.

Few minor reports, though:

• Architecture diagram not visible in the HTML version (in the PDF it is OK)
• Section 3.2, 4th paragraph: "For this reason, earlier versions of VOTable recommended placing the ID attribute before any references to it, but there may be cases where the opposite is more appropriate."
  • If I was a client developper, this sentence is very useful as I know I will have to not rely on the ID position. But if I was a VOTable provider, does it mean I can do whathever I want? It sounds like it does not matter anymore. Would there be some kind of good practice useful to give here, or an example that can help a VOTable provider (which is often a DAL protocol) to organise a VOTable in the best possible way?

Data Model Working Group

Grid & Web Services Working Group

All changes are minor and justified, and not affecting GWS activities.

• There is only one minor comment about MIVOT elements inside RESOURCE type="meta". This is not reflected in the schema, so, is it considered free text? Is this OK for parsers or should it be escaped in some way?
• Also, a personal comment as I am slightly confused by the UNKNOWN valid value for COOSYS refposition (as refposition is optional). It could be better to remove it from the list as setting it as UNKNOWN is not adding info.

As said, this minor version's changes are well documented, so we approve it from the GWS WG.

-- JesusSalgado - 2024-07-17

Registry Working Group

Semantics Working Group

Data Curation & Preservation Interest Group

Ok with minor reports:

• look& feel comments: lines artefact in the HTML output (section 2 and 7). The link texts are often the section number instead of the section title.
• link to /votable-1.5.xsd is broken (section 3)
• COOSYS semantic: it is case sensititve (in VizieR, the GALACTIC is in lower case) ?
• "unit SHOULD conform to the VOUnits". It seems to be a step backwards from the previous version that said " unit string *is* defined in reference [3]"
• MIVOT is stipulated in section 3.6 but it doesn't appear neither in schemas 7.1,7.2not in xsd (appendix B) -

Education Interest Group

Knowledge Discovery Interest Group

Operations Interest Group

Radio Astronomy Interest Group

Solar System Interest Group

My review is focused on the changes listed in the change log, as this is a rather mature document. Just a couple of minor notes:

• In Section 3.5 "TIMESYS Element", the description of timeorigin notes that Besselian years are tied to the ET timescale, but "ET" is not a permitted value for timescale. Looking at the vocabulary, it seems ET is equivalent to the TT timescale. It would make sense then to note parenthetically that ET is equivalent to TT as a convenience for readers and users. For example: "...and Besselian years to the ET (equivalent to TT) timescale...".
• If the "positioning advice for ID and corresponding references" is referring to the fourth paragraph of section 3.2 "name, ID and ref attributes" (i.e., "The relative position of an ID..."), then I don't see that any advice is being provided. There is a statement that position might have an effect, and that the effect might be positive or negative depending on some unspecified circumstances, but there is no guidance and no actionable information offered. I would expect, for example, a statement along the lines of, "Typically, placing the ID first in the stream improves performance, but when [some unusual circumstance] occurs, placing the reference(s) first may decrease overall processing time." Or, if it is less certain than that, something like "The relative position of ID and ref can affect the performance of streaming parsers [in some specified way], but the direction and magnitude of the effect is context-dependent and difficult to predict."

Theory Interest Group

Time Domain Interest Group

Standards and Processes Committee

TCG Vote

If you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.