Certain prop>values have restrictions for data type or allowed values

[Telos-sa]

User Story

Several prop>value(s) have data type or allowed value restrictions that are not outlined in the schema. For example, the system-characteristic props for 'cloud-service-model' and 'cloud-deployment-model' both require the values to be a token, and to match one of the allowed values. These restrictions are not outlined in the schema, and the only restriction for prop>value is string data type (regex pattern "\S(.*\S)?").

There are other instances of this such as: users>prop>name="type" inventory-items>prop>name="allows-authenticated-scan"&"is-scanned"

Additionally, some prop>value's have data type restrictions as well (datetime example):

This restrictions is not outlined in the schema, and the only restriction for prop>value is string data type (regex pattern "\S(.*\S)?").

Goals

Introduce prop restrictions in the schema for these special cases

This could be in the form of custom prop structures for these special cases (rather than all props being assembled the same way) Or Add these in as actual elements, rather than as props, and provide an "enum" sub-element for them like status:

Dependencies

No response

Acceptance Criteria

• [X] 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

[wendellpiez]

The issue raised here appears to be a question with regard to Metaschema-based schema generation - whether, where and how to express certain rules (kinds of rules) in the JSON Schema or even (by implication) other schema technology (XSD, RNG, XML DTD, what have you).

As such it's a bit deep and involves subtle tradeoffs - while its scope spans across Metaschema and its implementations (specifically, schema generators in either/both oscal-cli and metaschema-xslt) - and not only OSCAL.

Keep in mind that certain rules expressible in metaschemas - regex matching, index-based cross-checking, etc. - will always go beyond what JSON Schema can do. This is why we do not advocate or recommend relying on this alone for 'one-stop shopping' of validation and quality checks. :-)

IIRC according to Metaschema, enumerations are generally not put into a schema when they are extensible (allow-other='yes') i.e. only 'guidelines'.

In the context of testing out options with available processors, alterations to OSCAL could certainly be considered here. But proposals for modifications to Metaschema implementations or specs (regarding how to map metaschema rules into schemas) should be taken up in that context, not as an OSCAL issue.

It's nice to see the attention to this, thank you!