Ability to Prevent Override for Designated Metaschema Content

[brian-ruf]

User Story:

As an OSCAL developer, it would help to have confidence that metadata and back-matter assemblies are consistently implemented in all layers of OSCAL.

The current metaschema to schema mechanisms take a modular approach, with each of those assemblies in separate modules; however, the mechanism allows these assemblies to be overridden, which introduces the risk that these assemblies are implemented differently at different OSCAL levels.

While this override feature is desirable for some modules, it is not desirable for these assemblies. A metaschema directive to prevent the override of certain assemblies would eliminate this risk.

Goals:

Establish a metaschema mechanism to prevent the override of a specific assembly and/or an entire module.

Dependencies:

None

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.

• A module and/or assembly can be flagged to prevent the override, and the mechanism converts the metaschema to a schema while honoring this directive.

[david-waltermire]

We are implementing a stop-gap in #475. This issue will be revisited in a future sprint.

[wendellpiez]

Currently, any attempt to override a definition is detected and warned against by the Metaschema Schematron, which effectively prohibits it since these checks must pass before any merge.

Internally, the Metaschema still follows the rule that clashing definitions (whether a purposeful override or accidental) are resolved in favor of the definition appearing last. This permits graceful overriding if we want it -- and is arguably better (whether overriding is permitted, discouraged or formally prohibited) than producing a runtime error.

[wendellpiez]

September 5

Suggest we review current status against requirements and close the Issue or rewrite it as appropriate.

[david-waltermire]

Assigning to sprint 25 to either add a new issue or close.

[wendellpiez]

@brianrugsa could you review the current status for this issue?

In the current implementation, a Schematron currently prevents any overriding in any metaschema committed and run through CI/CD. We can relax this rule after further discussion. Besides the flag you propose, there are other potential solutions to the problem as stated.

[brian-ruf]

@wendellpiez I believe the current mechanisms address the concern, even though it wasn't accomplished with a flag. I agree with closing this issue.