Fixed invalid schema generation test content

[david-waltermire]

Committer Notes

Updated invalid content causing tests to fail. Also alternated value named to make debugging easier.

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.

[david-waltermire]

@wendellpiez As part of your review, please check if this change will break your tests.

[wendellpiez]

Executing these tests over generated schemas in metaschema-xslt is still a to-do, so this should have no direct impact.

However, there is a question of what may happen higher in the (refactored) stack, e.g. OSCAL, where tests are run over generated schemas.

@nikitawootten-nist @aj-stein-nist would you be able to confirm this is not a breaking change anywhere?

[wendellpiez]

@aj-stein-nist also, per our conversation - usnistgov/metaschema-xslt#56 provides a scaffolding for XProc-based schema testing including sets of known-valid and known-invalid instances; a next step would be harnessing this set of unit tests under it.

Except this is a JSON test. So, another thing we need to determine is how to run those under metaschema-xslt. Do we need to find a way to use XProc 3.0? https://spec.xproc.org/master/head/validation/#c.validate-with-json-schema

[wendellpiez]

Just a sanity check here - 'prop1', 'prop2' and 'prop3' become the name property on the property (object) while 'value1'-'value3' are the (nominal) field values. But the error being corrected is actually the repeated ID, not the "prop1", which is actually permitted to be the name of the field in both places (according to the schema).

Suggestion (non-blocking) - since in OSCAL, prop objects are not fields but assemblies (with value flags), this is now somewhat confusing. Maybe the elements in the test need to be named something else, to illustrate this feature on fields?