Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add identifiers to each inline constraint in Metaschema definitions of NIST OSCAL models #2088

Open
5 tasks
aj-stein-gsa opened this issue Dec 5, 2024 · 3 comments

Comments

@aj-stein-gsa
Copy link
Contributor

User Story

As a developer who makes use of OSCAL models and embedded data modeling requirements defined by assembly, field, and flag constraints, I would like every constraint (allowed-values; expect; matches; index; index-has-key; has-cardinality; etc.) to have a defined @id field. Per the Metaschema specification, this field is optional. A

Goals

  • Clearly identify the source of a constraint violation to the specific location(s) where the inline definition occurs for the model
  • Allow output from unit and integration tests with sample valid and invalid test fixture data to selective filter output based on ID (NOTE: because core NIST OSCAL models have inline constraints without identifiers, this is highly impractical)

Dependencies

No response

Acceptance Criteria

  • All OSCAL website and readme documentation affected by the changes in this issue have been updated. Changes to the OSCAL website can be made in the docs/content directory of your branch.
  • A Pull Request (PR) is submitted that fully addresses the goals of this User Story. This issue is referenced in the PR.
  • The CI-CD build process runs without any reported errors on the PR. This can be confirmed by reviewing that all checks have passed in the PR.

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

Revisions

No response

@Telos-sa
Copy link

This is something we would like to see as well. We plan to use these IDs in customer facing reports, along with other information from the oscal-cli validation results, to help customers identify and remediate issues in their data/OSCAL.

Currently the "id" changes for NIST constraints on each run, which makes it difficult to track whether a specific error has been remediated or not on subsequent oscal-cli validations.

@iMichaela
Copy link
Contributor

Thank you @aj-stein-gsa and @Telos-sa . I think the request is reasonable and we can look at scheduling it early next year, after wrapping up some ongoing work.

@aj-stein-gsa
Copy link
Contributor Author

I will send a PR for consideration then later today or Sunday.

aj-stein-gsa added a commit to aj-stein-gsa/OSCAL that referenced this issue Dec 15, 2024
aj-stein-gsa added a commit to aj-stein-gsa/OSCAL that referenced this issue Dec 16, 2024
aj-stein-gsa added a commit to aj-stein-gsa/OSCAL that referenced this issue Dec 16, 2024
aj-stein-gsa added a commit to aj-stein-gsa/OSCAL that referenced this issue Dec 16, 2024
aj-stein-gsa added a commit to aj-stein-gsa/OSCAL that referenced this issue Dec 16, 2024
aj-stein-gsa added a commit to aj-stein-gsa/OSCAL that referenced this issue Dec 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Needs Triage
Development

No branches or pull requests

3 participants