Integrate use of oscal-prose-module.xsd in metaschema.xsd

[david-waltermire]

Committer Notes

The markup support in the metaschema.xsd is fairly simple and incomplete. This PR replaces the current markup support with the markup data types provided by the oscal-prose-module.xsd.

All Submissions:

• Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't other open Pull Requests for the same update/change?
• Have you squashed any non-relevant commits and commit messages? [instructions]
• Do all automated CI/CD checks pass?

Changes to Core Features:

• Have you added an explanation of what your changes do and why you'd like us to include them?
• Have you written new tests for your core changes, as applicable?
• Have you included examples of how to use your new feature(s)?
• Have you updated all website](https://pages.nist.gov/metaschema) and readme documentation affected by the changes you made? Changes to the website can be made in the website/content directory of your branch.

[wendellpiez]

There are some issues in bidirectional conversion here that need to be specified before I can finish the tooling to support this.

Specifically, when an image is given on its own line, this could be either <p><img src="some.svg"/></p> and plain <img src="some.svg"/>. As information loss goes this is probably tolerable, but it does require choosing between them.

Plus (relating to usnistgov/OSCAL#1151), determining that tools support the features defined should ultimately entail unit testing for Markdown conversions (new Issue?), along with a nice little specification (even a grammar?!) for OSCAL Markdown. Currently, Markdown conversions in the XSLT pipeline are handmade/bespoke, while in oscal-java an external library (with adjustments) is being used. This will not be sustainable for scaling across platforms.

(Should we solicit interest in helping develop a grammar for OSCAL Markdown?)

[aj-stein-nist]

along with a nice little specification (even a grammar?!) for OSCAL Markdown. Currently, Markdown conversions in the XSLT pipeline are handmade/bespoke, while in oscal-java an external library (with adjustments) is being used. This will not be sustainable for scaling across platforms.

(Should we solicit interest in helping develop a grammar for OSCAL Markdown?)

I know OSCAL has been in development for a few years, and the implementations and lack of standards around Markdown flavors has evolved somewhat. Is there, in fact an explicit idea of an OSCAL Markdown or you are proposing that now? If not existent yet, would it not be better if we target the emerging CommonMark specification? It appears the Java library we are using in metaschema-java that you reference is doing that too. I only point this out because it started in 2012 but did not see wider-spread adoption uptick until GitHub adopted it in 2019 over their specific GHFM variant, which is pretty late in OSCAL history.

[wendellpiez]

Would that it were even that simple. This is a discussion that has been going on for some time. A subset of CommonMark is probably wise. Every feature offered by any particular flavor or implementation of CommonMark (including arbitrary HTML)? -- maybe not. I say "OSCAL Markdown" not because I want to invent something new but because we are going to have to write some kind of spec.

[david-waltermire]

@wendellpiez I am creating a new develop branch to merge next-version Metaschema changes into. We can use this as an integration branch for further changes to our toolchains. I am going to merge this there.