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

One question: What is the enforcement mechanism for ensuring new keys are lower-case? The string format given in section 3.2 (page 18) would not constrain that if it is used for defining the type in the schema. My bitter experience is that rules that are not enforced are not really rules - they're suggestions, and they're frequently ignored...

• There is no enforcement mechanism other than people's goodwill. We have actually discussed whether we should have a process (like the VEPs) to manage standard keys, but the use cases seemed to diverse. Most standard keys will come in through a standard (see ADQL or TAPRegExt), and then hopefully the review catches offenders. We cannot really fix the RE for the key because regrettably there are existing mixed-case keys out there. With this rule, you can at least scold people who managed to define keys conflicting after case folding... -- MarkusDemleitner - 2025-03-11

Language issues:

• Page 9, "Note" at top: The first sentence doesn't make a lot of sense. There's an "either" without an "or", and three instances of "of" that I can't sort out. It's not clear which "of", if any, should be an "or"; or if perhaps the "either" is in the wrong place. There's also a reference to "the above two types", but I don't see a list of two types preceding or in close proximity to this Note. A section reference might be better for this.
  • Uh, that whole box was perhaps written in too much of a hurry. I've tried to rewrite it to better make the point: "don't do what happened with ADQL and TAPRegExt " (and prefer Vocabularies if what you're doing isn't closely tied to your specific standard). Is it better now? -- MarkusDemleitner - 2025-03-11
• Page 10, last sentence currently reads: "This can be be [sic] done by deriving a new key metadatum type derived by extension from the vstd:StandardKey." This would be better stated: "This can be done by deriving a new key metadatum type by extension from the vstd:StandardKey type."
  • Thanks for that suggestion; I've shortened it a bit more still and changed the mood to conjunctive, as I don't believe such an application-specific extension will ever happen, and I'm not a fan of that that kind of language ("one day somebody could...") in a normative document in the first place. -- MarkusDemleitner - 2025-03-11
• Page 11, section 3.2, first sentence: "defined" should be "defines", I think.
  • Umm, no, I think that's been largely fine. But I didn't like the double definition and made the second "defined" a "discussed" -- MarkusDemleitner - 2025-03-11
• Page 17, bottom paragraph: The sentence that begins "Consequently" seems to ramble on for about twice as long as it should, losing focus halfway home. I suspect that the second semi-colon in "vs:ParamHTTP:" should be a full stop ("."), and that the next word ("parameters") should be capitalized as the start of a new sentence.
  • In retrospect, this entire passage is a lot of effort for something that, to my knowledge, has never been tried in the 13 years since this standard has been passed. Ah well. I've tried to clarified the language nevertheless. -- MarkusDemleitner - 2025-03-11
• Page 18, top paragraph (continued from previous page). The sentence that begins "This minimizes" uses the word "list" in both noun and verb senses, which is mildly jarring. The second "list" would be better as "include", or "detail', or "provide", or "enumerate", etc. The sentence itself is so long I would also recommend, as a matter of readbility, replacing the colon with a full stop (".") and starting a new sentence: "That is, when the list service instance description...".
• Page 18, section 3.2, first sentence: Recommend replacing the parenthetical "defined" with "described" for better flow.
  • Ah... yeah, described is even better than my "discussed" proposed above, so that's what it got now. -- MarkusDemleitner - 2025-03-11

- Anne Raugh

The proposed fixes are in https://github.com/ivoa-std/StandardsRegExt/pull/12 -- MarkusDemleitner - 2025-03-11

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.