Difference: VOTable15RFC (1 vs. 33)

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 2024-11-25) includes updates to address RFC comments on the previous draft (PR 2024-02-13).

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

VOTable 1.5 is a backward-compatible revision.

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

• Astropy added support for VOTable 1.5 with PR #16856 and it will be included in the upcoming Astropy v7.0 release.

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 VO Paris validator 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

Ok for us

All comments have been adressed and solved on Github

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?

• Thanks for reporting the problem with the architecture diagram in the HTML version. I've confirmed that it works well when I build locally and will confirm its correct appearance in the published versions moving forward.
• Regarding the advice on the relative positions of IDs and refs, I've added this sentence which hopefully clarifies the situation, "In practical terms, no requirement has ever been placed on the ordering of an ID and its references, so VOTable creators are free to use either order and parsers/consumers should handle either." See github PR #62.

Data Model Working Group

I went through the PRs in the version 1.5 milestone to review just the changes for this version. The updates are good and I don't see any major issues.

Comments:

• on this page - Validators: the second block, "The validates VOTable 1.5", appears to be describing a web-validator, but has no link to one.
• on the document
  • TIMESYS: I agree with Anne's comment regarding the 'ET' timescale. The new text specifically linking Besselian years to a timescale which is not obviously supported by the following timescale value set is a bit awkward. One needs to look at the descriptions in the vocabulary to make the connection between ET and TT.
  • Relative position of ID and ref: I agree with Gregory/Anne's comment on this too. The new text doesn't give direction. To me, it reads as "The relative position of these can effect performance, we used to recommend ID go first, but we don't any more because there MAY be cases where the opposite is true".
  • RESOURCE: MIVOT connection. There are a couple comments on this and why its not reflected in the element hierarchy or schema.
    • This is a good example of when one would use a RESOURCE with 'type="meta", and maybe that paragraph should start with "For example, a RESOURCE qualified by"...
    • My recollection is that this connection, <VODML> block in the RESOURCE, is OK because clients know to ignore any unrecognized nodes in the RESOURCE. I was thinking that a reminder of that would be useful here, but doing a quick scan of the document, i don't see anything that makes this statement.

-- MarkCresitelloDittmar - 2024-08-23

• I've fixed (hopefully permanently) this page's missing link to the VO Paris validator which has occasionally disappeared for some reason.
• I implemented the following changes in github PR #62:
  • Anne's suggestion regarding ET and TT.
  • Regarding the advice on the relative positions of IDs and refs, this sentence was added to hopefully clarify the situation, "In practical terms, no requirement has ever been placed on the ordering of an ID and its references, so VOTable creators are free to use either order and parsers/consumers should handle either."
  • Your MIVOT suggestion "For example, a RESOURCE qualified by"...
  • A little text explaining that the VOTable schema does allow MIVOT elements (in fact a RESOURCE may contain any legal xml).

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

• In github PR #62, I added some text explaining that the VOTable schema does allow MIVOT elements (in fact a RESOURCE may contain any legal xml).

• Having UNKNOWN as an option for an optional attribute is indeed inconsistent, but UNKNOWN cannot be removed since it is needed for the Astronomical Coordinates model, and we can't make refposition required without breaking backward compatibility.

Registry Working Group

OK, we foresee no Registry-related issue.

Semantics Working Group

Happy to endorse the 1.5 version ! -- SebastienDerriere - 2024-12-18

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

Thank you for reviewing the often forgotten HTML version!

• I will look into a fix of the line artifacts, but if this doesn't have an obvious easy fix I will file an issue to be fixed for the next version.
• The link to the schema in section 3 is the correct final location for the schema, but in an annoying circular dependency it won't be there until we publish the final REC for this version.
• The COOSYS semantics are case sensitive, so I think for VOTable 1.5 GALACTIC should be upper case.
• Although this seems like a step backward, the SHOULD language is the most accurate instruction for parsers since they should allow other values but are under no obligation to understand them.
  • The rationale here was discussed at some length in the "VOTable and VOUnits" thread in apps/2023-May -- MarkTaylor - 2024-11-18
• In github PR #62, I added some text text explaining that the VOTable schema does allow MIVOT elements (in fact a RESOURCE may contain any legal xml).

Education Interest Group

Knowledge Discovery Interest Group

Operations Interest Group

Ok for us.

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

Thanks for pointing these out. There was much agreement from the other reviewers.

I addressed these comments in github PR #62 by taking your suggestion regarding ET and TT, and by adding this sentence regarding ordering of ID and ref, "In practical terms, no requirement has ever been placed on the ordering of an ID and its references, so VOTable creators are free to use either order and parsers/consumers should handle either."

-- TomDonaldson - 2024-11-16

Theory Interest Group

Time Domain Interest Group

I've just noted a reference that hasn't been updated in the appendix A1. "The definitions enclosed in this appendix are not part of VOTable 1.1". I suggest a non numerical reference: "...are not part of VOTable standard"

-- PierreFernique - 2024-11-28

Thanks, Pierre. I've taken your suggestion in pull request 65 (https://github.com/ivoa-std/VOTable/pull/65) and it will appear in the next published version.

-- TomDonaldson - 2024-12-03

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.

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 2024-11-25) includes updates to address RFC comments on the previous draft (PR 2024-02-13).

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

VOTable 1.5 is a backward-compatible revision.

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

• Astropy added support for VOTable 1.5 with PR #16856 and it will be included in the upcoming Astropy v7.0 release.

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 VO Paris validator 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

Ok for us

All comments have been adressed and solved on Github

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?

• Thanks for reporting the problem with the architecture diagram in the HTML version. I've confirmed that it works well when I build locally and will confirm its correct appearance in the published versions moving forward.
• Regarding the advice on the relative positions of IDs and refs, I've added this sentence which hopefully clarifies the situation, "In practical terms, no requirement has ever been placed on the ordering of an ID and its references, so VOTable creators are free to use either order and parsers/consumers should handle either." See github PR #62.

Data Model Working Group

I went through the PRs in the version 1.5 milestone to review just the changes for this version. The updates are good and I don't see any major issues.

Comments:

• on this page - Validators: the second block, "The validates VOTable 1.5", appears to be describing a web-validator, but has no link to one.
• on the document
  • TIMESYS: I agree with Anne's comment regarding the 'ET' timescale. The new text specifically linking Besselian years to a timescale which is not obviously supported by the following timescale value set is a bit awkward. One needs to look at the descriptions in the vocabulary to make the connection between ET and TT.
  • Relative position of ID and ref: I agree with Gregory/Anne's comment on this too. The new text doesn't give direction. To me, it reads as "The relative position of these can effect performance, we used to recommend ID go first, but we don't any more because there MAY be cases where the opposite is true".
  • RESOURCE: MIVOT connection. There are a couple comments on this and why its not reflected in the element hierarchy or schema.
    • This is a good example of when one would use a RESOURCE with 'type="meta", and maybe that paragraph should start with "For example, a RESOURCE qualified by"...
    • My recollection is that this connection, <VODML> block in the RESOURCE, is OK because clients know to ignore any unrecognized nodes in the RESOURCE. I was thinking that a reminder of that would be useful here, but doing a quick scan of the document, i don't see anything that makes this statement.

-- MarkCresitelloDittmar - 2024-08-23

• I've fixed (hopefully permanently) this page's missing link to the VO Paris validator which has occasionally disappeared for some reason.
• I implemented the following changes in github PR #62:
  • Anne's suggestion regarding ET and TT.
  • Regarding the advice on the relative positions of IDs and refs, this sentence was added to hopefully clarify the situation, "In practical terms, no requirement has ever been placed on the ordering of an ID and its references, so VOTable creators are free to use either order and parsers/consumers should handle either."
  • Your MIVOT suggestion "For example, a RESOURCE qualified by"...
  • A little text explaining that the VOTable schema does allow MIVOT elements (in fact a RESOURCE may contain any legal xml).

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

• In github PR #62, I added some text explaining that the VOTable schema does allow MIVOT elements (in fact a RESOURCE may contain any legal xml).

• Having UNKNOWN as an option for an optional attribute is indeed inconsistent, but UNKNOWN cannot be removed since it is needed for the Astronomical Coordinates model, and we can't make refposition required without breaking backward compatibility.

Registry Working Group

OK, we foresee no Registry-related issue.

Semantics Working Group

Happy to endorse the 1.5 version ! -- SebastienDerriere - 2024-12-18

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

Thank you for reviewing the often forgotten HTML version!

• I will look into a fix of the line artifacts, but if this doesn't have an obvious easy fix I will file an issue to be fixed for the next version.
• The link to the schema in section 3 is the correct final location for the schema, but in an annoying circular dependency it won't be there until we publish the final REC for this version.
• The COOSYS semantics are case sensitive, so I think for VOTable 1.5 GALACTIC should be upper case.
• Although this seems like a step backward, the SHOULD language is the most accurate instruction for parsers since they should allow other values but are under no obligation to understand them.
  • The rationale here was discussed at some length in the "VOTable and VOUnits" thread in apps/2023-May -- MarkTaylor - 2024-11-18
• In github PR #62, I added some text text explaining that the VOTable schema does allow MIVOT elements (in fact a RESOURCE may contain any legal xml).

Education Interest Group

Knowledge Discovery Interest Group

Operations Interest Group

Ok for us.

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

Thanks for pointing these out. There was much agreement from the other reviewers.

I addressed these comments in github PR #62 by taking your suggestion regarding ET and TT, and by adding this sentence regarding ordering of ID and ref, "In practical terms, no requirement has ever been placed on the ordering of an ID and its references, so VOTable creators are free to use either order and parsers/consumers should handle either."

-- TomDonaldson - 2024-11-16

Theory Interest Group

Time Domain Interest Group

I've just noted a reference that hasn't been updated in the appendix A1. "The definitions enclosed in this appendix are not part of VOTable 1.1". I suggest a non numerical reference: "...are not part of VOTable standard"

-- PierreFernique - 2024-11-28

Thanks, Pierre. I've taken your suggestion in pull request 65 (https://github.com/ivoa-std/VOTable/pull/65) and it will appear in the next published version.

-- TomDonaldson - 2024-12-03

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.

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 2024-11-25) includes updates to address RFC comments on the previous draft (PR 2024-02-13).

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

VOTable 1.5 is a backward-compatible revision.

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

• Astropy added support for VOTable 1.5 with PR #16856 and it will be included in the upcoming Astropy v7.0 release.

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 VO Paris validator 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

Ok for us

All comments have been adressed and solved on Github

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?

• Thanks for reporting the problem with the architecture diagram in the HTML version. I've confirmed that it works well when I build locally and will confirm its correct appearance in the published versions moving forward.
• Regarding the advice on the relative positions of IDs and refs, I've added this sentence which hopefully clarifies the situation, "In practical terms, no requirement has ever been placed on the ordering of an ID and its references, so VOTable creators are free to use either order and parsers/consumers should handle either." See github PR #62.

Data Model Working Group

I went through the PRs in the version 1.5 milestone to review just the changes for this version. The updates are good and I don't see any major issues.

Comments:

• on this page - Validators: the second block, "The validates VOTable 1.5", appears to be describing a web-validator, but has no link to one.
• on the document
  • TIMESYS: I agree with Anne's comment regarding the 'ET' timescale. The new text specifically linking Besselian years to a timescale which is not obviously supported by the following timescale value set is a bit awkward. One needs to look at the descriptions in the vocabulary to make the connection between ET and TT.
  • Relative position of ID and ref: I agree with Gregory/Anne's comment on this too. The new text doesn't give direction. To me, it reads as "The relative position of these can effect performance, we used to recommend ID go first, but we don't any more because there MAY be cases where the opposite is true".
  • RESOURCE: MIVOT connection. There are a couple comments on this and why its not reflected in the element hierarchy or schema.
    • This is a good example of when one would use a RESOURCE with 'type="meta", and maybe that paragraph should start with "For example, a RESOURCE qualified by"...
    • My recollection is that this connection, <VODML> block in the RESOURCE, is OK because clients know to ignore any unrecognized nodes in the RESOURCE. I was thinking that a reminder of that would be useful here, but doing a quick scan of the document, i don't see anything that makes this statement.

-- MarkCresitelloDittmar - 2024-08-23

• I've fixed (hopefully permanently) this page's missing link to the VO Paris validator which has occasionally disappeared for some reason.
• I implemented the following changes in github PR #62:
  • Anne's suggestion regarding ET and TT.
  • Regarding the advice on the relative positions of IDs and refs, this sentence was added to hopefully clarify the situation, "In practical terms, no requirement has ever been placed on the ordering of an ID and its references, so VOTable creators are free to use either order and parsers/consumers should handle either."
  • Your MIVOT suggestion "For example, a RESOURCE qualified by"...
  • A little text explaining that the VOTable schema does allow MIVOT elements (in fact a RESOURCE may contain any legal xml).

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

• In github PR #62, I added some text explaining that the VOTable schema does allow MIVOT elements (in fact a RESOURCE may contain any legal xml).

• Having UNKNOWN as an option for an optional attribute is indeed inconsistent, but UNKNOWN cannot be removed since it is needed for the Astronomical Coordinates model, and we can't make refposition required without breaking backward compatibility.

Registry Working Group

OK, we foresee no Registry-related issue.

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

Thank you for reviewing the often forgotten HTML version!

• I will look into a fix of the line artifacts, but if this doesn't have an obvious easy fix I will file an issue to be fixed for the next version.
• The link to the schema in section 3 is the correct final location for the schema, but in an annoying circular dependency it won't be there until we publish the final REC for this version.
• The COOSYS semantics are case sensitive, so I think for VOTable 1.5 GALACTIC should be upper case.
• Although this seems like a step backward, the SHOULD language is the most accurate instruction for parsers since they should allow other values but are under no obligation to understand them.
  • The rationale here was discussed at some length in the "VOTable and VOUnits" thread in apps/2023-May -- MarkTaylor - 2024-11-18
• In github PR #62, I added some text text explaining that the VOTable schema does allow MIVOT elements (in fact a RESOURCE may contain any legal xml).

Education Interest Group

Knowledge Discovery Interest Group

Operations Interest Group

Ok for us.

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

Thanks for pointing these out. There was much agreement from the other reviewers.

I addressed these comments in github PR #62 by taking your suggestion regarding ET and TT, and by adding this sentence regarding ordering of ID and ref, "In practical terms, no requirement has ever been placed on the ordering of an ID and its references, so VOTable creators are free to use either order and parsers/consumers should handle either."

-- TomDonaldson - 2024-11-16

Theory Interest Group

Time Domain Interest Group

I've just noted a reference that hasn't been updated in the appendix A1. "The definitions enclosed in this appendix are not part of VOTable 1.1". I suggest a non numerical reference: "...are not part of VOTable standard"

-- PierreFernique - 2024-11-28

Thanks, Pierre. I've taken your suggestion in pull request 65 (https://github.com/ivoa-std/VOTable/pull/65) and it will appear in the next published version.

-- TomDonaldson - 2024-12-03

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.

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 2024-11-25) includes updates to address RFC comments on the previous draft (PR 2024-02-13).

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

VOTable 1.5 is a backward-compatible revision.

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

• Astropy added support for VOTable 1.5 with PR #16856 and it will be included in the upcoming Astropy v7.0 release.

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 VO Paris validator 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

Ok for us

All comments have been adressed and solved on Github

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?

• Thanks for reporting the problem with the architecture diagram in the HTML version. I've confirmed that it works well when I build locally and will confirm its correct appearance in the published versions moving forward.
• Regarding the advice on the relative positions of IDs and refs, I've added this sentence which hopefully clarifies the situation, "In practical terms, no requirement has ever been placed on the ordering of an ID and its references, so VOTable creators are free to use either order and parsers/consumers should handle either." See github PR #62.

Data Model Working Group

I went through the PRs in the version 1.5 milestone to review just the changes for this version. The updates are good and I don't see any major issues.

Comments:

• on this page - Validators: the second block, "The validates VOTable 1.5", appears to be describing a web-validator, but has no link to one.
• on the document
  • TIMESYS: I agree with Anne's comment regarding the 'ET' timescale. The new text specifically linking Besselian years to a timescale which is not obviously supported by the following timescale value set is a bit awkward. One needs to look at the descriptions in the vocabulary to make the connection between ET and TT.
  • Relative position of ID and ref: I agree with Gregory/Anne's comment on this too. The new text doesn't give direction. To me, it reads as "The relative position of these can effect performance, we used to recommend ID go first, but we don't any more because there MAY be cases where the opposite is true".
  • RESOURCE: MIVOT connection. There are a couple comments on this and why its not reflected in the element hierarchy or schema.
    • This is a good example of when one would use a RESOURCE with 'type="meta", and maybe that paragraph should start with "For example, a RESOURCE qualified by"...
    • My recollection is that this connection, <VODML> block in the RESOURCE, is OK because clients know to ignore any unrecognized nodes in the RESOURCE. I was thinking that a reminder of that would be useful here, but doing a quick scan of the document, i don't see anything that makes this statement.

-- MarkCresitelloDittmar - 2024-08-23

• I've fixed (hopefully permanently) this page's missing link to the VO Paris validator which has occasionally disappeared for some reason.
• I implemented the following changes in github PR #62:
  • Anne's suggestion regarding ET and TT.
  • Regarding the advice on the relative positions of IDs and refs, this sentence was added to hopefully clarify the situation, "In practical terms, no requirement has ever been placed on the ordering of an ID and its references, so VOTable creators are free to use either order and parsers/consumers should handle either."
  • Your MIVOT suggestion "For example, a RESOURCE qualified by"...
  • A little text explaining that the VOTable schema does allow MIVOT elements (in fact a RESOURCE may contain any legal xml).

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

• In github PR #62, I added some text explaining that the VOTable schema does allow MIVOT elements (in fact a RESOURCE may contain any legal xml).

• Having UNKNOWN as an option for an optional attribute is indeed inconsistent, but UNKNOWN cannot be removed since it is needed for the Astronomical Coordinates model, and we can't make refposition required without breaking backward compatibility.

Registry Working Group

OK, we foresee no Registry-related issue.

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

Thank you for reviewing the often forgotten HTML version!

• I will look into a fix of the line artifacts, but if this doesn't have an obvious easy fix I will file an issue to be fixed for the next version.
• The link to the schema in section 3 is the correct final location for the schema, but in an annoying circular dependency it won't be there until we publish the final REC for this version.
• The COOSYS semantics are case sensitive, so I think for VOTable 1.5 GALACTIC should be upper case.
• Although this seems like a step backward, the SHOULD language is the most accurate instruction for parsers since they should allow other values but are under no obligation to understand them.
  • The rationale here was discussed at some length in the "VOTable and VOUnits" thread in apps/2023-May -- MarkTaylor - 2024-11-18
• In github PR #62, I added some text text explaining that the VOTable schema does allow MIVOT elements (in fact a RESOURCE may contain any legal xml).

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

Thanks for pointing these out. There was much agreement from the other reviewers.

I addressed these comments in github PR #62 by taking your suggestion regarding ET and TT, and by adding this sentence regarding ordering of ID and ref, "In practical terms, no requirement has ever been placed on the ordering of an ID and its references, so VOTable creators are free to use either order and parsers/consumers should handle either."

-- TomDonaldson - 2024-11-16

Theory Interest Group

Time Domain Interest Group

I've just noted a reference that hasn't been updated in the appendix A1. "The definitions enclosed in this appendix are not part of VOTable 1.1". I suggest a non numerical reference: "...are not part of VOTable standard"

-- PierreFernique - 2024-11-28

Thanks, Pierre. I've taken your suggestion in pull request 65 (https://github.com/ivoa-std/VOTable/pull/65) and it will appear in the next published version.

-- TomDonaldson - 2024-12-03

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.

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 2024-11-25) includes updates to address RFC comments on the previous draft (PR 2024-02-13).

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

VOTable 1.5 is a backward-compatible revision.

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

• Astropy added support for VOTable 1.5 with PR #16856 and it will be included in the upcoming Astropy v7.0 release.

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 VO Paris validator 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

Ok for us

All comments have been adressed and solved on Github

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?

• Thanks for reporting the problem with the architecture diagram in the HTML version. I've confirmed that it works well when I build locally and will confirm its correct appearance in the published versions moving forward.
• Regarding the advice on the relative positions of IDs and refs, I've added this sentence which hopefully clarifies the situation, "In practical terms, no requirement has ever been placed on the ordering of an ID and its references, so VOTable creators are free to use either order and parsers/consumers should handle either." See github PR #62.

Data Model Working Group

I went through the PRs in the version 1.5 milestone to review just the changes for this version. The updates are good and I don't see any major issues.

Comments:

• on this page - Validators: the second block, "The validates VOTable 1.5", appears to be describing a web-validator, but has no link to one.
• on the document
  • TIMESYS: I agree with Anne's comment regarding the 'ET' timescale. The new text specifically linking Besselian years to a timescale which is not obviously supported by the following timescale value set is a bit awkward. One needs to look at the descriptions in the vocabulary to make the connection between ET and TT.
  • Relative position of ID and ref: I agree with Gregory/Anne's comment on this too. The new text doesn't give direction. To me, it reads as "The relative position of these can effect performance, we used to recommend ID go first, but we don't any more because there MAY be cases where the opposite is true".
  • RESOURCE: MIVOT connection. There are a couple comments on this and why its not reflected in the element hierarchy or schema.
    • This is a good example of when one would use a RESOURCE with 'type="meta", and maybe that paragraph should start with "For example, a RESOURCE qualified by"...
    • My recollection is that this connection, <VODML> block in the RESOURCE, is OK because clients know to ignore any unrecognized nodes in the RESOURCE. I was thinking that a reminder of that would be useful here, but doing a quick scan of the document, i don't see anything that makes this statement.

-- MarkCresitelloDittmar - 2024-08-23

• I've fixed (hopefully permanently) this page's missing link to the VO Paris validator which has occasionally disappeared for some reason.
• I implemented the following changes in github PR #62:
  • Anne's suggestion regarding ET and TT.
  • Regarding the advice on the relative positions of IDs and refs, this sentence was added to hopefully clarify the situation, "In practical terms, no requirement has ever been placed on the ordering of an ID and its references, so VOTable creators are free to use either order and parsers/consumers should handle either."
  • Your MIVOT suggestion "For example, a RESOURCE qualified by"...
  • A little text explaining that the VOTable schema does allow MIVOT elements (in fact a RESOURCE may contain any legal xml).

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

• In github PR #62, I added some text explaining that the VOTable schema does allow MIVOT elements (in fact a RESOURCE may contain any legal xml).

• Having UNKNOWN as an option for an optional attribute is indeed inconsistent, but UNKNOWN cannot be removed since it is needed for the Astronomical Coordinates model, and we can't make refposition required without breaking backward compatibility.

Registry Working Group

OK, we foresee no Registry-related issue.

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

Thank you for reviewing the often forgotten HTML version!

• I will look into a fix of the line artifacts, but if this doesn't have an obvious easy fix I will file an issue to be fixed for the next version.
• The link to the schema in section 3 is the correct final location for the schema, but in an annoying circular dependency it won't be there until we publish the final REC for this version.
• The COOSYS semantics are case sensitive, so I think for VOTable 1.5 GALACTIC should be upper case.
• Although this seems like a step backward, the SHOULD language is the most accurate instruction for parsers since they should allow other values but are under no obligation to understand them.
  • The rationale here was discussed at some length in the "VOTable and VOUnits" thread in apps/2023-May -- MarkTaylor - 2024-11-18
• In github PR #62, I added some text text explaining that the VOTable schema does allow MIVOT elements (in fact a RESOURCE may contain any legal xml).

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

Thanks for pointing these out. There was much agreement from the other reviewers.

I addressed these comments in github PR #62 by taking your suggestion regarding ET and TT, and by adding this sentence regarding ordering of ID and ref, "In practical terms, no requirement has ever been placed on the ordering of an ID and its references, so VOTable creators are free to use either order and parsers/consumers should handle either."

-- TomDonaldson - 2024-11-16

Theory Interest Group

Time Domain Interest Group

I've just noted a reference that hasn't been updated in the appendix A1. "The definitions enclosed in this appendix are not part of VOTable 1.1". I suggest a non numerical reference: "...are not part of VOTable standard"

-- PierreFernique - 2024-11-28

Thanks, Pierre. I've taken your suggestion in pull request 65 (https://github.com/ivoa-std/VOTable/pull/65) and it will appear in the next published version.

-- TomDonaldson - 2024-12-03

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.

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 2024-11-25) includes updates to address RFC comments on the previous draft (PR 2024-02-13).

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

VOTable 1.5 is a backward-compatible revision.

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

• Astropy added support for VOTable 1.5 with PR #16856 and it will be included in the upcoming Astropy v7.0 release.

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 VO Paris validator 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?

• Thanks for reporting the problem with the architecture diagram in the HTML version. I've confirmed that it works well when I build locally and will confirm its correct appearance in the published versions moving forward.
• Regarding the advice on the relative positions of IDs and refs, I've added this sentence which hopefully clarifies the situation, "In practical terms, no requirement has ever been placed on the ordering of an ID and its references, so VOTable creators are free to use either order and parsers/consumers should handle either." See github PR #62.

Data Model Working Group

I went through the PRs in the version 1.5 milestone to review just the changes for this version. The updates are good and I don't see any major issues.

Comments:

• on this page - Validators: the second block, "The validates VOTable 1.5", appears to be describing a web-validator, but has no link to one.
• on the document
  • TIMESYS: I agree with Anne's comment regarding the 'ET' timescale. The new text specifically linking Besselian years to a timescale which is not obviously supported by the following timescale value set is a bit awkward. One needs to look at the descriptions in the vocabulary to make the connection between ET and TT.
  • Relative position of ID and ref: I agree with Gregory/Anne's comment on this too. The new text doesn't give direction. To me, it reads as "The relative position of these can effect performance, we used to recommend ID go first, but we don't any more because there MAY be cases where the opposite is true".
  • RESOURCE: MIVOT connection. There are a couple comments on this and why its not reflected in the element hierarchy or schema.
    • This is a good example of when one would use a RESOURCE with 'type="meta", and maybe that paragraph should start with "For example, a RESOURCE qualified by"...
    • My recollection is that this connection, <VODML> block in the RESOURCE, is OK because clients know to ignore any unrecognized nodes in the RESOURCE. I was thinking that a reminder of that would be useful here, but doing a quick scan of the document, i don't see anything that makes this statement.

-- MarkCresitelloDittmar - 2024-08-23

• I've fixed (hopefully permanently) this page's missing link to the VO Paris validator which has occasionally disappeared for some reason.
• I implemented the following changes in github PR #62:
  • Anne's suggestion regarding ET and TT.
  • Regarding the advice on the relative positions of IDs and refs, this sentence was added to hopefully clarify the situation, "In practical terms, no requirement has ever been placed on the ordering of an ID and its references, so VOTable creators are free to use either order and parsers/consumers should handle either."
  • Your MIVOT suggestion "For example, a RESOURCE qualified by"...
  • A little text explaining that the VOTable schema does allow MIVOT elements (in fact a RESOURCE may contain any legal xml).

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

• In github PR #62, I added some text explaining that the VOTable schema does allow MIVOT elements (in fact a RESOURCE may contain any legal xml).

• Having UNKNOWN as an option for an optional attribute is indeed inconsistent, but UNKNOWN cannot be removed since it is needed for the Astronomical Coordinates model, and we can't make refposition required without breaking backward compatibility.

Registry Working Group

OK, we foresee no Registry-related issue.

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

Thank you for reviewing the often forgotten HTML version!

• I will look into a fix of the line artifacts, but if this doesn't have an obvious easy fix I will file an issue to be fixed for the next version.
• The link to the schema in section 3 is the correct final location for the schema, but in an annoying circular dependency it won't be there until we publish the final REC for this version.
• The COOSYS semantics are case sensitive, so I think for VOTable 1.5 GALACTIC should be upper case.
• Although this seems like a step backward, the SHOULD language is the most accurate instruction for parsers since they should allow other values but are under no obligation to understand them.
  • The rationale here was discussed at some length in the "VOTable and VOUnits" thread in apps/2023-May -- MarkTaylor - 2024-11-18
• In github PR #62, I added some text text explaining that the VOTable schema does allow MIVOT elements (in fact a RESOURCE may contain any legal xml).

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

Thanks for pointing these out. There was much agreement from the other reviewers.

I addressed these comments in github PR #62 by taking your suggestion regarding ET and TT, and by adding this sentence regarding ordering of ID and ref, "In practical terms, no requirement has ever been placed on the ordering of an ID and its references, so VOTable creators are free to use either order and parsers/consumers should handle either."

-- TomDonaldson - 2024-11-16

Theory Interest Group

Time Domain Interest Group

I've just noted a reference that hasn't been updated in the appendix A1. "The definitions enclosed in this appendix are not part of VOTable 1.1". I suggest a non numerical reference: "...are not part of VOTable standard"

-- PierreFernique - 2024-11-28

Thanks, Pierre. I've taken your suggestion in pull request 65 (https://github.com/ivoa-std/VOTable/pull/65) and it will appear in the next published version.

-- TomDonaldson - 2024-12-03

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.

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 2024-11-25) includes updates to address RFC comments on the previous draft (PR 2024-02-13).

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

VOTable 1.5 is a backward-compatible revision.

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

• Astropy added support for VOTable 1.5 with PR #16856 and it will be included in the upcoming Astropy v7.0 release.

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 VO Paris validator 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?

• Thanks for reporting the problem with the architecture diagram in the HTML version. I've confirmed that it works well when I build locally and will confirm its correct appearance in the published versions moving forward.
• Regarding the advice on the relative positions of IDs and refs, I've added this sentence which hopefully clarifies the situation, "In practical terms, no requirement has ever been placed on the ordering of an ID and its references, so VOTable creators are free to use either order and parsers/consumers should handle either." See github PR #62.

Data Model Working Group

I went through the PRs in the version 1.5 milestone to review just the changes for this version. The updates are good and I don't see any major issues.

Comments:

• on this page - Validators: the second block, "The validates VOTable 1.5", appears to be describing a web-validator, but has no link to one.
• on the document
  • TIMESYS: I agree with Anne's comment regarding the 'ET' timescale. The new text specifically linking Besselian years to a timescale which is not obviously supported by the following timescale value set is a bit awkward. One needs to look at the descriptions in the vocabulary to make the connection between ET and TT.
  • Relative position of ID and ref: I agree with Gregory/Anne's comment on this too. The new text doesn't give direction. To me, it reads as "The relative position of these can effect performance, we used to recommend ID go first, but we don't any more because there MAY be cases where the opposite is true".
  • RESOURCE: MIVOT connection. There are a couple comments on this and why its not reflected in the element hierarchy or schema.
    • This is a good example of when one would use a RESOURCE with 'type="meta", and maybe that paragraph should start with "For example, a RESOURCE qualified by"...
    • My recollection is that this connection, <VODML> block in the RESOURCE, is OK because clients know to ignore any unrecognized nodes in the RESOURCE. I was thinking that a reminder of that would be useful here, but doing a quick scan of the document, i don't see anything that makes this statement.

-- MarkCresitelloDittmar - 2024-08-23

• I've fixed (hopefully permanently) this page's missing link to the VO Paris validator which has occasionally disappeared for some reason.
• I implemented the following changes in github PR #62:
  • Anne's suggestion regarding ET and TT.
  • Regarding the advice on the relative positions of IDs and refs, this sentence was added to hopefully clarify the situation, "In practical terms, no requirement has ever been placed on the ordering of an ID and its references, so VOTable creators are free to use either order and parsers/consumers should handle either."
  • Your MIVOT suggestion "For example, a RESOURCE qualified by"...
  • A little text explaining that the VOTable schema does allow MIVOT elements (in fact a RESOURCE may contain any legal xml).

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

• In github PR #62, I added some text explaining that the VOTable schema does allow MIVOT elements (in fact a RESOURCE may contain any legal xml).

• Having UNKNOWN as an option for an optional attribute is indeed inconsistent, but UNKNOWN cannot be removed since it is needed for the Astronomical Coordinates model, and we can't make refposition required without breaking backward compatibility.

Registry Working Group

OK, we foresee no Registry-related issue.

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

Thank you for reviewing the often forgotten HTML version!

• I will look into a fix of the line artifacts, but if this doesn't have an obvious easy fix I will file an issue to be fixed for the next version.
• The link to the schema in section 3 is the correct final location for the schema, but in an annoying circular dependency it won't be there until we publish the final REC for this version.
• The COOSYS semantics are case sensitive, so I think for VOTable 1.5 GALACTIC should be upper case.
• Although this seems like a step backward, the SHOULD language is the most accurate instruction for parsers since they should allow other values but are under no obligation to understand them.
  • The rationale here was discussed at some length in the "VOTable and VOUnits" thread in apps/2023-May -- MarkTaylor - 2024-11-18
• In github PR #62, I added some text text explaining that the VOTable schema does allow MIVOT elements (in fact a RESOURCE may contain any legal xml).

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

Thanks for pointing these out. There was much agreement from the other reviewers.

I addressed these comments in github PR #62 by taking your suggestion regarding ET and TT, and by adding this sentence regarding ordering of ID and ref, "In practical terms, no requirement has ever been placed on the ordering of an ID and its references, so VOTable creators are free to use either order and parsers/consumers should handle either."

-- TomDonaldson - 2024-11-16

Theory Interest Group

Time Domain Interest Group

I've just noted a reference that hasn't been updated in the appendix A1. "The definitions enclosed in this appendix are not part of VOTable 1.1". I suggest a non numerical reference: "...are not part of VOTable standard"

-- PierreFernique - 2024-11-28

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.

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 2024-11-25) includes updates to address RFC comments on the previous draft (PR 2024-02-13).

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

VOTable 1.5 is a backward-compatible revision.

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

• Astropy added support for VOTable 1.5 with PR #16856 and it will be included in the upcoming Astropy v7.0 release.

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 VO Paris validator 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?

• Thanks for reporting the problem with the architecture diagram in the HTML version. I've confirmed that it works well when I build locally and will confirm its correct appearance in the published versions moving forward.
• Regarding the advice on the relative positions of IDs and refs, I've added this sentence which hopefully clarifies the situation, "In practical terms, no requirement has ever been placed on the ordering of an ID and its references, so VOTable creators are free to use either order and parsers/consumers should handle either." See github PR #62.

Data Model Working Group

I went through the PRs in the version 1.5 milestone to review just the changes for this version. The updates are good and I don't see any major issues.

Comments:

• on this page - Validators: the second block, "The validates VOTable 1.5", appears to be describing a web-validator, but has no link to one.
• on the document
  • TIMESYS: I agree with Anne's comment regarding the 'ET' timescale. The new text specifically linking Besselian years to a timescale which is not obviously supported by the following timescale value set is a bit awkward. One needs to look at the descriptions in the vocabulary to make the connection between ET and TT.
  • Relative position of ID and ref: I agree with Gregory/Anne's comment on this too. The new text doesn't give direction. To me, it reads as "The relative position of these can effect performance, we used to recommend ID go first, but we don't any more because there MAY be cases where the opposite is true".
  • RESOURCE: MIVOT connection. There are a couple comments on this and why its not reflected in the element hierarchy or schema.
    • This is a good example of when one would use a RESOURCE with 'type="meta", and maybe that paragraph should start with "For example, a RESOURCE qualified by"...
    • My recollection is that this connection, <VODML> block in the RESOURCE, is OK because clients know to ignore any unrecognized nodes in the RESOURCE. I was thinking that a reminder of that would be useful here, but doing a quick scan of the document, i don't see anything that makes this statement.

-- MarkCresitelloDittmar - 2024-08-23

• I've fixed (hopefully permanently) this page's missing link to the VO Paris validator which has occasionally disappeared for some reason.
• I implemented the following changes in github PR #62:
  • Anne's suggestion regarding ET and TT.
  • Regarding the advice on the relative positions of IDs and refs, this sentence was added to hopefully clarify the situation, "In practical terms, no requirement has ever been placed on the ordering of an ID and its references, so VOTable creators are free to use either order and parsers/consumers should handle either."
  • Your MIVOT suggestion "For example, a RESOURCE qualified by"...
  • A little text explaining that the VOTable schema does allow MIVOT elements (in fact a RESOURCE may contain any legal xml).

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

• In github PR #62, I added some text explaining that the VOTable schema does allow MIVOT elements (in fact a RESOURCE may contain any legal xml).

• Having UNKNOWN as an option for an optional attribute is indeed inconsistent, but UNKNOWN cannot be removed since it is needed for the Astronomical Coordinates model, and we can't make refposition required without breaking backward compatibility.

Registry Working Group

OK, we foresee no Registry-related issue.

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

Thank you for reviewing the often forgotten HTML version!

• I will look into a fix of the line artifacts, but if this doesn't have an obvious easy fix I will file an issue to be fixed for the next version.
• The link to the schema in section 3 is the correct final location for the schema, but in an annoying circular dependency it won't be there until we publish the final REC for this version.
• The COOSYS semantics are case sensitive, so I think for VOTable 1.5 GALACTIC should be upper case.
• Although this seems like a step backward, the SHOULD language is the most accurate instruction for parsers since they should allow other values but are under no obligation to understand them.
  • The rationale here was discussed at some length in the "VOTable and VOUnits" thread in apps/2023-May -- MarkTaylor - 2024-11-18
• In github PR #62, I added some text text explaining that the VOTable schema does allow MIVOT elements (in fact a RESOURCE may contain any legal xml).

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

Thanks for pointing these out. There was much agreement from the other reviewers.

I addressed these comments in github PR #62 by taking your suggestion regarding ET and TT, and by adding this sentence regarding ordering of ID and ref, "In practical terms, no requirement has ever been placed on the ordering of an ID and its references, so VOTable creators are free to use either order and parsers/consumers should handle either."

-- TomDonaldson - 2024-11-16

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.

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

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.

• Astropy added support for VOTable 1.5 with PR #16856 and it will be included in the upcoming Astropy v7.0 release.

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 VO Paris validator 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?

• Thanks for reporting the problem with the architecture diagram in the HTML version. I've confirmed that it works well when I build locally and will confirm its correct appearance in the published versions moving forward.
• Regarding the advice on the relative positions of IDs and refs, I've added this sentence which hopefully clarifies the situation, "In practical terms, no requirement has ever been placed on the ordering of an ID and its references, so VOTable creators are free to use either order and parsers/consumers should handle either." See github PR #62.

Data Model Working Group

I went through the PRs in the version 1.5 milestone to review just the changes for this version. The updates are good and I don't see any major issues.

Comments:

• on this page - Validators: the second block, "The validates VOTable 1.5", appears to be describing a web-validator, but has no link to one.
• on the document
  • TIMESYS: I agree with Anne's comment regarding the 'ET' timescale. The new text specifically linking Besselian years to a timescale which is not obviously supported by the following timescale value set is a bit awkward. One needs to look at the descriptions in the vocabulary to make the connection between ET and TT.
  • Relative position of ID and ref: I agree with Gregory/Anne's comment on this too. The new text doesn't give direction. To me, it reads as "The relative position of these can effect performance, we used to recommend ID go first, but we don't any more because there MAY be cases where the opposite is true".
  • RESOURCE: MIVOT connection. There are a couple comments on this and why its not reflected in the element hierarchy or schema.
    • This is a good example of when one would use a RESOURCE with 'type="meta", and maybe that paragraph should start with "For example, a RESOURCE qualified by"...
    • My recollection is that this connection, <VODML> block in the RESOURCE, is OK because clients know to ignore any unrecognized nodes in the RESOURCE. I was thinking that a reminder of that would be useful here, but doing a quick scan of the document, i don't see anything that makes this statement.

-- MarkCresitelloDittmar - 2024-08-23

• I've fixed (hopefully permanently) this page's missing link to the VO Paris validator which has occasionally disappeared for some reason.
• I implemented the following changes in github PR #62:
  • Anne's suggestion regarding ET and TT.
  • Regarding the advice on the relative positions of IDs and refs, this sentence was added to hopefully clarify the situation, "In practical terms, no requirement has ever been placed on the ordering of an ID and its references, so VOTable creators are free to use either order and parsers/consumers should handle either."
  • Your MIVOT suggestion "For example, a RESOURCE qualified by"...
  • A little text explaining that the VOTable schema does allow MIVOT elements (in fact a RESOURCE may contain any legal xml).

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

• In github PR #62, I added some text explaining that the VOTable schema does allow MIVOT elements (in fact a RESOURCE may contain any legal xml).

• Having UNKNOWN as an option for an optional attribute is indeed inconsistent, but UNKNOWN cannot be removed since it is needed for the Astronomical Coordinates model, and we can't make refposition required without breaking backward compatibility.

Registry Working Group

OK, we foresee no Registry-related issue.

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

Thank you for reviewing the often forgotten HTML version!

• I will look into a fix of the line artifacts, but if this doesn't have an obvious easy fix I will file an issue to be fixed for the next version.
• The link to the schema in section 3 is the correct final location for the schema, but in an annoying circular dependency it won't be there until we publish the final REC for this version.
• The COOSYS semantics are case sensitive, so I think for VOTable 1.5 GALACTIC should be upper case.
• Although this seems like a step backward, the SHOULD language is the most accurate instruction for parsers since they should allow other values but are under no obligation to understand them.
  • The rationale here was discussed at some length in the "VOTable and VOUnits" thread in apps/2023-May -- MarkTaylor - 2024-11-18
• In github PR #62, I added some text text explaining that the VOTable schema does allow MIVOT elements (in fact a RESOURCE may contain any legal xml).

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

Thanks for pointing these out. There was much agreement from the other reviewers.

I addressed these comments in github PR #62 by taking your suggestion regarding ET and TT, and by adding this sentence regarding ordering of ID and ref, "In practical terms, no requirement has ever been placed on the ordering of an ID and its references, so VOTable creators are free to use either order and parsers/consumers should handle either."

-- TomDonaldson - 2024-11-16

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.

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.

• Astropy added support for VOTable 1.5 with PR #16856 and it will be included in the upcoming Astropy v7.0 release.

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 VO Paris validator 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?

• Thanks for reporting the problem with the architecture diagram in the HTML version. I've confirmed that it works well when I build locally and will confirm its correct appearance in the published versions moving forward.
• Regarding the advice on the relative positions of IDs and refs, I've added this sentence which hopefully clarifies the situation, "In practical terms, no requirement has ever been placed on the ordering of an ID and its references, so VOTable creators are free to use either order and parsers/consumers should handle either." See github PR #62.

Data Model Working Group

I went through the PRs in the version 1.5 milestone to review just the changes for this version. The updates are good and I don't see any major issues.

Comments:

• on this page - Validators: the second block, "The validates VOTable 1.5", appears to be describing a web-validator, but has no link to one.
• on the document
  • TIMESYS: I agree with Anne's comment regarding the 'ET' timescale. The new text specifically linking Besselian years to a timescale which is not obviously supported by the following timescale value set is a bit awkward. One needs to look at the descriptions in the vocabulary to make the connection between ET and TT.
  • Relative position of ID and ref: I agree with Gregory/Anne's comment on this too. The new text doesn't give direction. To me, it reads as "The relative position of these can effect performance, we used to recommend ID go first, but we don't any more because there MAY be cases where the opposite is true".
  • RESOURCE: MIVOT connection. There are a couple comments on this and why its not reflected in the element hierarchy or schema.
    • This is a good example of when one would use a RESOURCE with 'type="meta", and maybe that paragraph should start with "For example, a RESOURCE qualified by"...
    • My recollection is that this connection, <VODML> block in the RESOURCE, is OK because clients know to ignore any unrecognized nodes in the RESOURCE. I was thinking that a reminder of that would be useful here, but doing a quick scan of the document, i don't see anything that makes this statement.

-- MarkCresitelloDittmar - 2024-08-23

• I've fixed (hopefully permanently) this page's missing link to the VO Paris validator which has occasionally disappeared for some reason.
• I implemented the following changes in github PR #62:
  • Anne's suggestion regarding ET and TT.
  • Regarding the advice on the relative positions of IDs and refs, this sentence was added to hopefully clarify the situation, "In practical terms, no requirement has ever been placed on the ordering of an ID and its references, so VOTable creators are free to use either order and parsers/consumers should handle either."
  • Your MIVOT suggestion "For example, a RESOURCE qualified by"...
  • A little text explaining that the VOTable schema does allow MIVOT elements (in fact a RESOURCE may contain any legal xml).

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

• In github PR #62, I added some text explaining that the VOTable schema does allow MIVOT elements (in fact a RESOURCE may contain any legal xml).

• Having UNKNOWN as an option for an optional attribute is indeed inconsistent, but UNKNOWN cannot be removed since it is needed for the Astronomical Coordinates model, and we can't make refposition required without breaking backward compatibility.

Registry Working Group

OK, we foresee no Registry-related issue.

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

Thank you for reviewing the often forgotten HTML version!

• I will look into a fix of the line artifacts, but if this doesn't have an obvious easy fix I will file an issue to be fixed for the next version.
• The link to the schema in section 3 is the correct final location for the schema, but in an annoying circular dependency it won't be there until we publish the final REC for this version.
• The COOSYS semantics are case sensitive, so I think for VOTable 1.5 GALACTIC should be upper case.
• Although this seems like a step backward, the SHOULD language is the most accurate instruction for parsers since they should allow other values but are under no obligation to understand them.
  • The rationale here was discussed at some length in the "VOTable and VOUnits" thread in apps/2023-May -- MarkTaylor - 2024-11-18
• In github PR #62, I added some text text explaining that the VOTable schema does allow MIVOT elements (in fact a RESOURCE may contain any legal xml).

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

Thanks for pointing these out. There was much agreement from the other reviewers.

I addressed these comments in github PR #62 by taking your suggestion regarding ET and TT, and by adding this sentence regarding ordering of ID and ref, "In practical terms, no requirement has ever been placed on the ordering of an ID and its references, so VOTable creators are free to use either order and parsers/consumers should handle either."

-- TomDonaldson - 2024-11-16

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.

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.

• Astropy added support for VOTable 1.5 with PR #16856 and it will be included in the upcoming Astropy v7.0 release.

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 VO Paris validator 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?

• Thanks for reporting the problem with the architecture diagram in the HTML version. I've confirmed that it works well when I build locally and will confirm its correct appearance in the published versions moving forward.
• Regarding the advice on the relative positions of IDs and refs, I've added this sentence which hopefully clarifies the situation, "In practical terms, no requirement has ever been placed on the ordering of an ID and its references, so VOTable creators are free to use either order and parsers/consumers should handle either." See github PR #62.

Data Model Working Group

I went through the PRs in the version 1.5 milestone to review just the changes for this version. The updates are good and I don't see any major issues.

Comments:

• on this page - Validators: the second block, "The validates VOTable 1.5", appears to be describing a web-validator, but has no link to one.
• on the document
  • TIMESYS: I agree with Anne's comment regarding the 'ET' timescale. The new text specifically linking Besselian years to a timescale which is not obviously supported by the following timescale value set is a bit awkward. One needs to look at the descriptions in the vocabulary to make the connection between ET and TT.
  • Relative position of ID and ref: I agree with Gregory/Anne's comment on this too. The new text doesn't give direction. To me, it reads as "The relative position of these can effect performance, we used to recommend ID go first, but we don't any more because there MAY be cases where the opposite is true".
  • RESOURCE: MIVOT connection. There are a couple comments on this and why its not reflected in the element hierarchy or schema.
    • This is a good example of when one would use a RESOURCE with 'type="meta", and maybe that paragraph should start with "For example, a RESOURCE qualified by"...
    • My recollection is that this connection, <VODML> block in the RESOURCE, is OK because clients know to ignore any unrecognized nodes in the RESOURCE. I was thinking that a reminder of that would be useful here, but doing a quick scan of the document, i don't see anything that makes this statement.

-- MarkCresitelloDittmar - 2024-08-23

• I've fixed (hopefully permanently) this page's missing link to the VO Paris validator which has occasionally disappeared for some reason.
• I implemented the following changes in github PR #62:
  • Anne's suggestion regarding ET and TT.
  • Regarding the advice on the relative positions of IDs and refs, this sentence was added to hopefully clarify the situation, "In practical terms, no requirement has ever been placed on the ordering of an ID and its references, so VOTable creators are free to use either order and parsers/consumers should handle either."
  • Your MIVOT suggestion "For example, a RESOURCE qualified by"...
  • A little text explaining that the VOTable schema does allow MIVOT elements (in fact a RESOURCE may contain any legal xml).

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

• In github PR #62, I added some text explaining that the VOTable schema does allow MIVOT elements (in fact a RESOURCE may contain any legal xml).

• Having UNKNOWN as an option for an optional attribute is indeed inconsistent, but UNKNOWN cannot be removed since it is needed for the Astronomical Coordinates model, and we can't make refposition required without breaking backward compatibility.

Registry Working Group

OK, we foresee no Registry-related issue.

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

Thank you for reviewing the often forgotten HTML version!

• I will look into a fix of the line artifacts, but if this doesn't have an obvious easy fix I will file an issue to be fixed for the next version.
• The link to the schema in section 3 is the correct final location for the schema, but in an annoying circular dependency it won't be there until we publish the final REC for this version.
• The COOSYS semantics are case sensitive, so I think for VOTable 1.5 GALACTIC should be upper case.
• Although this seems like a step backward, the SHOULD language is the most accurate instruction for parsers since they should allow other values but are under no obligation to understand them.

• In github PR #62, I added some text text explaining that the VOTable schema does allow MIVOT elements (in fact a RESOURCE may contain any legal xml).

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

Thanks for pointing these out. There was much agreement from the other reviewers.

I addressed these comments in github PR #62 by taking your suggestion regarding ET and TT, and by adding this sentence regarding ordering of ID and ref, "In practical terms, no requirement has ever been placed on the ordering of an ID and its references, so VOTable creators are free to use either order and parsers/consumers should handle either."

-- TomDonaldson - 2024-11-16

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.

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

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

I went through the PRs in the version 1.5 milestone to review just the changes for this version. The updates are good and I don't see any major issues.

Comments:

• on this page - Validators: the second block, "The validates VOTable 1.5", appears to be describing a web-validator, but has no link to one.
• on the document
  • TIMESYS: I agree with Anne's comment regarding the 'ET' timescale. The new text specifically linking Besselian years to a timescale which is not obviously supported by the following timescale value set is a bit awkward. One needs to look at the descriptions in the vocabulary to make the connection between ET and TT.
  • Relative position of ID and ref: I agree with Gregory/Anne's comment on this too. The new text doesn't give direction. To me, it reads as "The relative position of these can effect performance, we used to recommend ID go first, but we don't any more because there MAY be cases where the opposite is true".
  • RESOURCE: MIVOT connection. There are a couple comments on this and why its not reflected in the element hierarchy or schema.
    • This is a good example of when one would use a RESOURCE with 'type="meta", and maybe that paragraph should start with "For example, a RESOURCE qualified by"...
    • My recollection is that this connection, <VODML> block in the RESOURCE, is OK because clients know to ignore any unrecognized nodes in the RESOURCE. I was thinking that a reminder of that would be useful here, but doing a quick scan of the document, i don't see anything that makes this statement.

-- MarkCresitelloDittmar - 2024-08-23

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

OK, we foresee no Registry-related issue.

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.

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

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

I went through the PRs in the version 1.5 milestone to review just the changes for this version. The updates are good and I don't see any major issues.

Comments:

• on this page - Validators: the second block, "The validates VOTable 1.5", appears to be describing a web-validator, but has no link to one.
• on the document
  • TIMESYS: I agree with Anne's comment regarding the 'ET' timescale. The new text specifically linking Besselian years to a timescale which is not obviously supported by the following timescale value set is a bit awkward. One needs to look at the descriptions in the vocabulary to make the connection between ET and TT.

• • RESOURCE: MIVOT connection. There are a couple comments on this and why its not reflected in the element hierarchy or schema.

• • • My recollection is that this connection, <VODML> block in the RESOURCE, is OK because clients know to ignore any unrecognized nodes in the RESOURCE. I was thinking that a reminder of that would be useful here, but doing a quick scan of the document, i don't see anything that makes this statement.

-- MarkCresitelloDittmar - 2024-08-23

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

OK, we foresee no Registry-related issue.

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.

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

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

I went through the PRs in the version 1.5 milestone to review just the changes for this version. The updates are good and I don't see any major issues.

Comments:

• on this page - Validators: the second block, "The validates VOTable 1.5", appears to be describing a web-validator, but has no link to one.
• on the document
  • TIMESYS: I agree with Anne's comment regarding the 'ET' timescale. The new text specifically linking Besselian years to a timescale which is not obviously supported by the following timescale value set is a bit awkward. One needs to look at the descriptions in the vocabulary to make the connection between ET and TT.
  • Relative position of ID and ref: I agree with Gregory/Anne's comment on this too. The new text doesn't give direction. To me, it reads as "The relative position of these can effect performance, we used to recommend ID go first, but we don't any more because there MAY be cases where the opposite is true".
  • RESOURCE: MIVOT connection. There are a couple comments on this and why its not reflected in the element hierarchy or schema.
    • This is a good example of when one would use a RESOURCE with 'type="meta", and maybe that paragraph should start with "For example, a RESOURCE qualified by"...
    • My recollection is that this connection, <VODML> block in the RESOURCE, is OK because clients know to ignore any unrecognized nodes in the RESOURCE. I was thinking that a reminder of that would be useful here, but doing a quick scan of the document, i don't see anything that makes this statement.

-- MarkCresitelloDittmar - 2024-08-23

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

OK, we foresee no Registry-related issue.

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.

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

I went through the PRs in the version 1.5 milestone to review just the changes for this version. The updates are good and I don't see any major issues.

Comments:

• on this page - Validators: the second block, "The validates VOTable 1.5", appears to be describing a web-validator, but has no link to one.
• on the document
  • TIMESYS: I agree with Anne's comment regarding the 'ET' timescale. The new text specifically linking Besselian years to a timescale which is not obviously supported by the following timescale value set is a bit awkward. One needs to look at the descriptions in the vocabulary to make the connection between ET and TT.
  • Relative position of ID and ref: I agree with Gregory/Anne's comment on this too. The new text doesn't give direction. To me, it reads as "The relative position of these can effect performance, we used to recommend ID go first, but we don't any more because there MAY be cases where the opposite is true".
  • RESOURCE: MIVOT connection. There are a couple comments on this and why its not reflected in the element hierarchy or schema.
    • This is a good example of when one would use a RESOURCE with 'type="meta", and maybe that paragraph should start with "For example, a RESOURCE qualified by"...
    • My recollection is that this connection, <VODML> block in the RESOURCE, is OK because clients know to ignore any unrecognized nodes in the RESOURCE. I was thinking that a reminder of that would be useful here, but doing a quick scan of the document, i don't see anything that makes this statement.

-- MarkCresitelloDittmar - 2024-08-23

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.