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

Is a this-system rule enforced over OSCAL components? #1978

Open
wendellpiez opened this issue Feb 2, 2024 · 0 comments
Open

Is a this-system rule enforced over OSCAL components? #1978

wendellpiez opened this issue Feb 2, 2024 · 0 comments
Labels

Comments

@wendellpiez
Copy link
Contributor

Question

In the SSP documentation, this-system is described as one of the possible allowed values of component/@type.

We could go further in constraining this usage, for example to ensure (a) no SSP has more than one component[@type='this-system'], (b) no SSP is without one, or (c) any other cardinality (or other) constraints around this value and the component it marks.

Testing current functionality in validating instances is a prerequisite for this Issue. I.e., we need to be able to run Constraint validators such as oscal-cli or (forthcoming) InspectorXSLT to detect whatever is outside the boundaries of the 'permissible'.

Questions:

  1. Are there unaddressed requirements for testing contraints around `component[@type='this-system']?
  2. Do the tools correctly enforce the rules we want (such as whether a component so marked is required or optional, cardinality)?
  3. How do we edit or amend the metaschema to provide for testing these constraints?

Hint: the Metaschema language has a rule called has-cardinality that could be used for this. (Ask us working on Metaschema for more details.)

But being able to test that it is working is more important than making it work, at this point. So that is the real question: how do we do that.

(Hint: validation unit tests. "Good" and "No good" test samples.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: Needs Triage
Development

No branches or pull requests

1 participant