StandardsRegExt-1.1 Proposed Recommendation: Request for Comments

StandardsRegExt is a Registry extension describing IVOA documents; it has been in use for a long while to say things like “this service implements Cone Search 1.04” in Registry records. Another common use is that the optional features in TAP services are being declared using StandardsRegExt.

This new release was prompted by some concerns voiced in 2022, in particular that we could not register endorsed notes until now (as these were defined after StandardsRegExt 1.0).

The PR is at https://ivoa.net/documents/StandardsRegExt/20240125/.

The document repository is available at https://github.com/ivoa-std/StandardsRegExt

Additionnaly, regularly updated builds during RFC are available from https://docs.g-vo.org/StandardsRegExt.pdf.

This is a minor, maintenance-type update. To review, you probably want to have a look at (page numbers given for the PR-PDF):

• pen and en are now legal document types (p. 13)
• preparing to drop vstd:StandardKeyEnumeration (for which we now have Vocabularies; it's still in the schema, even though no live instances are in the Registy. See the note on p. 9)
• we are now a bit more explicit on who can add keys (but there's no defined process as for vocabularies, so in most cases you would probably prefer these now; p. 19f)
• requiring new keys to be all-lowercase; that's a cautionary interoperability measure, because you're supposed to compare ivoids case-insensitively, except that case-folding fragment identifiers is not a good thing (p. 10)
• and a few purely clerical edits you can probably skip during review without any scruples.

Reference Interoperable Implementations

N/A, largely. We give some examples for where this is used above; otherwise, this update does not introduce anything requiring implementations.

Implementation Validators

To validate StandardsRegExt records, use standard XML schema tools. Given a schemaLocation attribute mapping IVOA namespace URIs to themselves, you can, for instance, use stilts xsdvalidate.

Comments from the IVOA Community during RFC/TCG review period: 2025-02-15 - 2025-03-30

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

• Comments from MarkTaylor:
  • Looks OK to me.

Comments from TCG member during the RFC/TCG Review Period: 2025-02-15 - 2025-03-30

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

Data Model Working Group

Grid & Web Services Working Group

Registry Working Group

Semantics Working Group

Data Curation & Preservation Interest Group

Thank to the StandardsRegExt (that I discover).

For vstd:Standard, the example is really useful (and HiPS is a good example).
I just regret the example existing in v1.0 showing the schemas namespace usage (for vstd:Standard). May be an extract of the standard Resource from v1.0 would be added.

For vstd:ServiceStandard
The interface uses param (instead of “key” for vstd:Standard) with an attribute “required”, “optional”, “ignore” – sounds good. I don’t see any possibility to add a default value used for “optional” – is it volunteer? (may be left to the targeted standard)

Good point to think about vocabulary !

Just a word about P3T which allows too to describe service. In a sens they complete each other, but are there plan (may be in a future version) to link possible OpenAPI document (P3T) in StandardRegExt? (note that OpenAPI is cited to describe services in DCAT)

Education Interest Group

Knowledge Discovery Interest Group

Operations Interest Group

Radio Astronomy Interest Group

Solar System Interest Group

Theory Interest Group

Time Domain Interest Group

Ok for me. - Pierre Fernique

Standards and Processes Committee

TCG Vote : Vote_start_date - Vote_end_date

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.