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

Current updates look good. On the pdf document that I've looked at (https://docs.g-vo.org/StandardsRegExt.pdf) the Note paragraphs were renderred a bit weird and sometimes out of context (like the one on page 14). Other than that it makes sense. I don't want to be picky but I would remove the `cgi-bin` from the example.

And just for my own clarification, the information in `StandardsRegExt` is meant to complement and actual service information. A GUI or other application that comes accross an SIA service (to use the example in the standard), can augment the information from the `capabilities` end point of the service with the standard information from the registry (add input parameters descriptions and/or units for example, or point to the actual standard etc.). Is that correct? If so, I imagine this will change if we start adopting OpenAPI for describing services.

• The StandardsRegExt interface element does not seem to be the most successful idea in the document. To our knowledge, this feature has never been used in practice, and we only keep it because dropping it would be a breaking changes (albeit a manageable one, because all relevant records are under direct IVOA control). It doesn't seem to be worth dropping this feature, though.
  
  As to OpenAPI documents: you are right that if we intend to make these discoverable in the Registry, StandardsRegExt would be the place. If there is material we could try this on, we could imagine adding a corresponding feature even in this release.
  
  -- MarkusDemleitner and RenaudSavalle - 2025-04-25

Data Access Layer Working Group

(The following comments are based on the current version on GitHub: 99abf6102620b2f5c7b1b36ba5695373650f3d4e)

This new version of StandardsRegExt looks good to me.

Here is a couple of general comments:

• Section 2.2:
  • Thank you for the note about old-fashioned pratice about standard keys defined in TAPRegExt 's. It is well noted for next version(s) of ADQL and TAPRegExt.
    
    
• In the future, one should think on how to integrate OpenAPI in StandardsRegExt (maybe more in VOResource). We do not provide yet OpenAPI documents in DAL standards but they are coming in new versions. What happen then if there are conflicts between the DAL standard's OpenAPI and its StandardRegExt record? Should OpenAPI replace the parameter description? I have no answers, but this is certainly something to keep in mind now (if it is easy to solve) or in the near future.

• Section B.1:
  • "This entailed some re-shuffling the the previous content."
    
    
• Section 2.3:
  • "that defines a a key named case-insensitive"
  • "in front of the hash character" ; all previous references to this character (#) is done with the term "pound (#) sign". If I am picky, this could be a bit confusing to have two ways to reference this character.
    
    
• Section 4.1:
  • Typo in the title: "Management of Standards Records"

Data Model Working Group

Distributed Services & Protocols Working Group

Reading the doc, I am not totally sure if the only changes for this version are the ones described in the "B.1 Changes since Rec-1.0" section.

If this is the case, the changes are controlled and without a small impact on the services update.

Only focusing on those changes and some document types have been added, we are having a small vocabulary there. rec, pr, wd, iwd, note, pen,… could require a short description or a reference that defines there (ideally both)

There is a typo on 4.1 Managment -> Management that has been mentioned by others.

Also, I understand that the OpenAPI documents reference, that could be added by a reference, I think, are not covered so I do not know if the authors could analyse the impact of adding support to them (as commented by others) or if this is the roadmap for a future version.

In general, the changes do not affect DSP so we approve the document.

-- JesusSalgado - 2025-05-02

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.