Catalog constraints added in oscal_catalog_metaschema.xml - see issue #1949

[iMichaela]

Committer Notes

Added metaschema constraints for catalog/group/part/@name to accept "statement" and for catalog/group/control/part/@name to accept "example". These changes allow more catalogs, frameworks (e.g. CSF v2) to be represented in OSCAL without extensions and ns not being able to be processed by GRC tools without a registry.

All Submissions:

• Have you selected the correct base branch per Contributing guidance?
• [ n/a] Have you set "Allow edits and access to secrets by maintainers"?
• Have you checked to ensure there aren't other open Pull Requests for the same update/change?
• [ n/a] Have you squashed any non-relevant commits and commit messages? [instructions]
• Do all automated CI/CD checks pass?

By submitting a pull request, you are agreeing to provide this contribution under the CC0 1.0 Universal public domain dedication.

(For reviewers: The wiki has guidance on code review and overall issue review for completeness.)

Changes to Core Features:

• Have you added an explanation of what your changes do and why you'd like us to include them?
• Have you written new tests for your core changes, as applicable?
• Have you included examples of how to use your new feature(s)?
• Have you updated all OSCAL website and readme documentation affected by the changes you made? Changes to the OSCAL website can be made in the docs/content directory of your branch.

[david-waltermire]

As a community member, I don't think this PR is ready. Comments inline.

[wendellpiez]

This breaks backward-compatibility for anyone who might be using the value 'statement', which is no longer permitted.

Please consider adding new value(s) but not removing any values already enumerated, at least until a 2.0 version.

[iMichaela]

This breaks backward-compatibility for anyone who might be using the value 'statement', which is no longer permitted.

Please consider adding new value(s) but not removing any values already enumerated, at least until a 2.0 version.

@wendellpiez The value statement for group/part@name was proposed by me in the initial PR and contested by Dave (see his comments). I followed his suggestions and replaced it with instruction. It is not in our current schema. Can you please elaborate on where do you see a backwards compatibility break?

[wendellpiez]

If the value is not in the current schema (and only being removed from the file in the branch), I retract my objection. Adding new values to the reserved namespace is fine.

I'm not super keen on 'instruction' however either - what is the requirement being addressed by it? Since users are free to mark parts in their own namespace however they like, or leave parts with no name. Is there a specific behavior to be attributed for the 'instruction' that could not be met, for example, by

<part>
  <title>Instructions</title>
  ...
</part>

which is already valid?

These are not blocking questions, but I ask because afaik they have not been addressed.

FWIW, not having a registry is not in itself a reason to add new values to enumerated lists. They still incur costs to downstream developers.

Discussed and addressed.

[wendellpiez]

lgtm