hotfix schema id

[wandmagic]

Committer Notes

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 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]

This is a pretty clean and simple change now and I am rethinking whether the formal regression test should be a blocker, in view of the need for this correction (as I understand it). If this is a breaking change we can fix it, and the testing work can continue on its own track.

@wandmagic I am not missing anything, do you think? (Comments @nikitawootten-nist ?) Should we meet if only briefly to review the impact (see the correction) in the OSCAL runtime?

[github-actions]

XSpec Test Results

  2 files  ±0  40 suites  ±0   0s ⏱️ ±0s
105 tests ±0  90 ✅ ±0  15 💤 ±0  0 ❌ ±0 
114 runs  ±0  99 ✅ ±0  15 💤 ±0  0 ❌ ±0 

Results for commit 692894a. ± Comparison against base commit 7637dd2.

[iMichaela]

@wendellpiez - this finding and fix is the result of @wandmagic review of OSCAL [dependabot PR#2001] (usnistgov/OSCAL#2001). We would like to use the latest metaschema-xslt with the OSCAL v1.2.0 release candidates. @wandmagic - Is this PR a blocker for the [dependabot PR#2001] (usnistgov/OSCAL#2001) since #2001 was not approved? @wendellpiez - Is this PR not an improvement? Thank you for working together to roll the ball and support the OSCAL v1.2.0 improved release candidate.

[wandmagic]

without this PR the json schemas do not generate correctly, and oscal repo does need a working version.
once this repo becomes stable it would be good to tag a release and update the submodule upstream.

[wendellpiez]

I would like to work this further in the context of unit testing all the schema production, but I do not want that to be a blocker at this time.

If @wandmagic and @nikitawootten-nist have tested runtimes and are confident that

• the generated JSON Schemas are now 'correct' to a documented spec (where?)
• they function correctly vis-a-vis tested document sets

then by all means let's proceed with this.

If it blows up, we know how to repair the deeper problem - bring Schema field testing on line.

[iMichaela]

I would like to work this further in the context of unit testing all the schema production, but I do not want that to be a blocker at this time.

If @wandmagic and @nikitawootten-nist have tested runtimes and are confident that

• the generated JSON Schemas are now 'correct' to a documented spec (where?)
• they function correctly vis-a-vis tested document sets

then by all means let's proceed with this.

If it blows up, we know how to repair the deeper problem - bring Schema field testing on line.

Thank you, @wendellpiez . Will you merge it any time soon? When you will do so, I will recreate the dependabot/metaschema-xslt in the OSCAL repo so we can proceed to the next step on getting ready the release candidates. I tested/generated locally the release candidates with @nikitawootten-nist 's branch created from the develop branch. I do not know fi @nikitawootten-nist tested the hotfix. I did not... Do you want me to?