Final omnibus updates

[iannevans]

(1) Numerous small wordsmithing changes.
(2) Split messenger and messenger_pdgid as agreed with Semantics.
(3) Moved the extension table summary table to the end of the section that defines the table entries.
(4) SIgnificant rewrites in section 6.

[bkhelifi]

All good for me, thanks a lot @iannevans

[mservillat]

Thanks for the many modifications and hard work to homogenise the text.

What is now section 6 is quite important to the discussion that will come after endorsement, so it should not be discarded. As it is now, it is truncated and limited to DataLink usages, while the concept of "specific tables" is also important to discuss further data discovery in a more generalised way. I am sure we can find a good formulation to express this solution in a paragraph. I however understand that the content of such a specialized table is not yet settled and requires more science cases. The proposition for a specialized response-function table as it is now could thus simply appear as an appendix. All this will then be discussed at the DM WG level.

About dataproduct_type = “measurements”, it is already planned to avoid its usage, so this paragraph can be removed. It is indeed written in the product-type vocabulary: "Because of its lack of specificity, this term should generally be avoided, and new, more precise terms should be introduced instead." (see https://www.ivoa.net/rdf/product-type/2026-01-15/product-type.html#measurements).

[Bonnarel]

Thanks for the many modifications and hard work to homogenise the text.

What is now section 6 is quite important to the discussion that will come after endorsement, so it should not be discarded. As it is now, it is truncated and limited to DataLink usages, while the concept of "specific tables" is also important to discuss further data discovery in a more generalised way. I am sure we can find a good formulation to express this solution in a paragraph. I however understand that the content of such a specialized table is not yet settled and requires more science cases. The proposition for a specialized response-function table as it is now could thus simply appear as an appendix. All this will then be discussed at the DM WG level.

About dataproduct_type = “measurements”, it is already planned to avoid its usage, so this paragraph can be removed. It is indeed written in the product-type vocabulary: "Because of its lack of specificity, this term should generally be avoided, and new, more precise terms should be introduced instead." (see https://www.ivoa.net/rdf/product-type/2026-01-15/product-type.html#measurements).

The "access section" was written by Mireille and myself. I mainly concentrated on DataLink subsection and Mireille on the specific description tables but we are both responsible of the whole due to extensive cross-reading before the pull request. I apologize that we were not able to propose it before interop, but it was admitted several weeks before interop that such a section will come and was needed. During the interop there was several announces that such a section was close to be posted and this didn't seem to be an issue to wait for it.

About the content : there is nothing new there. These ideas have been presented several times in emails, issues, Pull request comment or even in the case of Mireille in previous interop presentation. I remember writing an email in April which had almost the same content as the subsection on DataLink of last Mireille's PR. I also presented some High energy examples in my DAL talk about DataLink explicitly acknowledging the discussions in High Energy Interest Group.
In the general discussion about extensions at last interop, it was clear that the proposal to include response functions and advanced analysis data products in ObsCore was at least questionable and I participated to this discussion.

A compromise such as "various discovery and access methods are possible and are in the hands of data producers" seems to be reachable. But to do this we have to review these methods somewhere in the document. The data variability and the use cases show so different requirements that we have to browse somewhere what can be done. The whole section including the inputs by Ian and the specific table subsection could become an appendix such as "data access implementation note" as suggested by Mathieu .

I still plan to make a couple of comments on Ian's PR.