Generate and Publish OSCAL Metaschema without XML Entities

[aj-stein-nist]

User Story

As a NIST or community OSCAL developer, in order to more efficiently develop tooling that can statically or dynamically generate the Metaschema source files in ./src/metaschema (at that location at the time of this request) and potentially publish copies without the XML entities to reduce the burden of working with the current XML source version of the Metaschema definitions.

Goals

• Minimize or eliminate the burden of developing Metaschema-technology for OSCAL libraries (specifically for oscal-cli-nodejs (usnistgov/oscal-cli-nodejs#21), metaschema-node, and community libraries hindered by this choice, such as this PR discussed here and
• Improve compile and run-time security for different NIST and community libraries that must use software that support XML entity resolution

Dependencies

No response

Acceptance Criteria

• A spike is performed to determine:
  • review and select the simplest and fastest solution to implement, XSLT or otherwise (prototype code if necessary, PR merged into repo not mandatory)
  • write a spec document on how and when in the CI/CD pipeline process this is to be inserted (prototype code if necessary, PR merged into repo not mandatory)
  • consult the team and determine if the most appropriate or efficient approach is to 1) commit these versions into a directory in the repo adjacent to ./src/metaschema or 2) prefer another mechanism. Make this decision based on which decision is easier and faster than the other.
• Draft ADR and get team to review and approve
• Create follow-on issue to make this work "go to prod" and end up in main branch after ADR and spike is complete, before marking this issue as closed or resolved
• 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.

[nikitawootten-nist]

@aj-stein-nist regarding the first AC item:

• A minimal approach for resolving XML entities exists in this repository: https://github.com/nikitawootten-nist/oscal-resolved. This approach uses a simple identity transform to resolve the entities.
  • Depending on the approach taken for releasing these artifacts, additional processing may have to take place (such as adjusting the <import/> @href's to include a suffix (oscal-metadata-metaschema-RESOLVED.xml` as an example)
• Approach wise, I can see two:
  1. Publish the resolved metaschemas in a second repository with CI tooling to listen for new tags (on a new published release, push a new commit)
  2. Add the resolved metaschemas as release artifacts on the core OSCAL repository
     • These artifacts would likely need a suffix added to differentiate them from the source metaschemas (as discussed above)

Approach 2 is the simplest. With that in mind would an ADR and follow up issue be necessary?

[nikitawootten-nist]

Fixed via #1901