OSCAL XML schemas generated with simple data types that are not validating #181
Comments
david-waltermire
added a commit
to david-waltermire/metaschema-java-old
that referenced
this issue
Sep 18, 2023
…S is enabled causing XML schema type references to not be produced for attributes associated with flags. This change restores the correct behavior by adding a type.isGeneratedType conditional check. Resolves usnistgov/liboscal-java#181.
8 tasks
david-waltermire
added a commit
to david-waltermire/metaschema-java-old
that referenced
this issue
Sep 18, 2023
…S is enabled causing XML schema type references to not be produced for attributes associated with flags. This change restores the correct behavior by adding a type.isGeneratedType conditional check. Resolves usnistgov/liboscal-java#181.
david-waltermire
added a commit
to usnistgov/metaschema-java
that referenced
this issue
Sep 18, 2023
…S is enabled causing XML schema type references to not be produced for attributes associated with flags. This change restores the correct behavior by adding a type.isGeneratedType conditional check. Resolves usnistgov/liboscal-java#181. (#218)
aj-stein-nist
added a commit
that referenced
this issue
Sep 20, 2023
Update to upcoming metaschema-java release 0.12.2 to get updated XML schema generation type signature code from usnistgov/metaschema-java#218. Fixes #181.
5 tasks
5 tasks
aj-stein-nist
added a commit
that referenced
this issue
Sep 20, 2023
Update to upcoming metaschema-java release 0.12.2 to get updated XML schema generation type signature code from usnistgov/metaschema-java#218. Fixes #181.
github-project-automation
bot
moved this from Under Review
to Done
in NIST OSCAL Work Board
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
Users utilizing v1.0.1 of the oscal-cli have reported that with example OSCAL catalogs, the official OSCAL XML Schemas for catalog and other models show errors for inline definitions of fields and flags with
tokendata types marking elements as invalid if they have spaces (which is correct), but the CLI marks instances of these same model elements as valid with spaces when they have the same invalid spaces within them.Who is the bug affecting?
OSCAL content authors and developers of catalog generation and management tools using liboscal-java and/or the oscal-cli.
What is affected by this bug?
Validating content based on Metaschema-defined models of OSCAL document instances.
When does this occur?
Consistently.
How do we replicate the issue?
Output of v1.1.0 OSCAL Catalog XML Schema run against reported example document: https://gist.github.com/aj-stein-nist/1aaf162735f8971d6d014870bc394b78.
With oscal-cli 1.0.1, this document will validate without errors.
Expected behavior (i.e. solution)
Similar validation errors for any token datatype instance will occur for any instance that has spaces, which are invalid for the current Metaschema token datatypes.
Other Comments
This issue has been reported to the metaschema-java maintainer and a patch has been proposed.
The text was updated successfully, but these errors were encountered: