feat: add rules language system attribute to parameter constraint tests

[vijaygovindaraja]

Fixes #206

Summary

Adds a system attribute to the parameter-constraint/test assembly that identifies the rules language used to interpret the test expression. This enables tools to automatically validate that a parameter value meets the constraint, fulfilling the acceptance criteria in #206.

Metaschema change

Added define-flag name="system" as-type="uri" to the test assembly in oscal_control-common_metaschema.xml. The attribute is optional — when omitted, the expression is treated as informational only (preserving backwards compatibility).

Well-known system URIs defined:

• http://www.w3.org/TR/xmlschema-2/#regexs — W3C XML Schema regular expression
• https://www.w3.org/TR/xpath-31/ — XPath 3.1 expression
• https://csrc.nist.gov/ns/oscal/constraints/numeric-range — OSCAL numeric range (e.g., "1-65535")

Tool developers can define additional URIs for proprietary or domain-specific constraint languages.

Proof of concept validator

Included a Python proof-of-concept tool (src/utils/constraint-validator/validate-constraints.py) that demonstrates automatic validation of parameter values against constraint expressions. Supports regex and numeric range systems.

Example:

python validate-constraints.py example-catalog.json --param-values example-values.json

Output:

Found 2 parameter constraint(s)

  Parameter: ac-1_prm_1
    System:     http://www.w3.org/TR/xmlschema-2/#regexs
    Expression: \d+
    Value:      30
    Result:     PASS

  Parameter: ac-1_prm_2
    System:     https://csrc.nist.gov/ns/oscal/constraints/numeric-range
    Expression: 1-100
    Value:      10
    Result:     PASS

All constraints passed.

Design decisions

• The system attribute follows the same URI-based identification pattern used elsewhere in OSCAL (e.g., identification-system in metadata)
• Optional attribute ensures full backwards compatibility with existing OSCAL content
• Updated the expression field description to reference the system attribute

Happy to discuss alternative approaches or adjust the well-known URI definitions based on community feedback.

[vijaygovindaraja]

@david-waltermire @aj-stein-nist this addresses the user story in #206 — adding a system attribute to parameter constraint tests so tools can automatically validate parameter values against machine-executable rules.

the approach follows the URI-based identification pattern already used in OSCAL. kept it backwards compatible — the attribute is optional, so existing content is unaffected.

included a proof-of-concept validator in Python that demonstrates regex and numeric range validation against OSCAL catalog parameters. happy to adjust the well-known URIs or the metaschema modeling based on your feedback.

[iMichaela]

@vijaygovindaraja - Thank you for your contribution. Please follow the contributor's guidance available here: https://github.com/usnistgov/OSCAL/wiki/Contributing-to-OSCAL--development-and-maintenance#feature-branches

Also note that the PR needs to be opened per explicit guidance here against a target feature-* branch in OSCAL repo since this is not ready to be included in the next patch release.

In addition, due to the nature of the proposed change (a feature), please note that

1. any proposed feature requires support for all formats
2. any change (in particular a new feature) to the Catalog schema needs to be supported in the Profiles and Profiles Resolution Specification.
3. any new feature requires updates to existing pipeline for automatic testing and validation int the CI/CD pipeline.

Please let me know if you want me to create a branch for your new feature.

[vijaygovindaraja]

@iMichaela Thanks for the detailed guidance. Yes, please create a feature branch. I'll rebase against it and update the PR target. I'll also review the contributor docs and scope out the additional format support and profile resolution changes needed.

[iMichaela]

Related issues:

• Automatic validation of parameter value using rule-based constraints #206
• Optional Typing of Parameter Content #474

It is important to distinguished between validating that the value of a parameter that was set , depending on its type, and #1059 that identifies the need for full support of validation rules for controls' assessment and checks that must be executed to collect the evidence.

#1059 is related to, and will be affected by the proposed solution for #206 and #474 . OSCAL Foundation is currently working on the #1059.

[iMichaela]

The flag name system" is confusing.

[vijaygovindaraja]

Understood — I'll scope this to the parameter validation side and keep clear of the assessment rules work in #1059. Let me know once the feature branch is ready and I'll rebase.

[iMichaela]

@vijaygovindaraja - I created a branch for this feature: feat-parameter-constraints-test-206-474. Please submit your PR against this new branch. Please address the requested changes in the process. Thank you.

[vijaygovindaraja]

closing in favor of #2224 which targets the feat-parameter-constraints-test-206-474 branch and renames system to rules-language per the review feedback.