Is a this-system rule enforced over OSCAL components?

[wendellpiez]

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.)

[brian-ruf]

At a minimum, OSCAL should enforce cardinality of 0 or 1 for //component[@name='this-system']

Beyond that, I think it is important to allow organizations and frameworks owners to decide whether "this-system" is required either as a component or as a by-component descendant of implemented-requirement. (implemented-requirement/by-component or implemented-requirement/statement/by-component)