Open aj-stein-nist opened 8 months ago
It is awesome to see this with such specificity.
However we aren't quite there yet to a spec - I would like to see the desired results for this:
<model>
<define-field name="a0" as-type="positiveInteger" min-occurs="1" max-occurs="1"/>
<choice>
<define-field name="a" as-type="positiveInteger" min-occurs="1" max-occurs="1"/>
<define-field name="b" as-type="positiveInteger" min-occurs="1" max-occurs="1"/>
</choice>
<define-field name="ax" as-type="positiveInteger" min-occurs="1" max-occurs="1"/>
</model>
? just a little closer to RL - though ph oscal-cli already does this correctly? comments, @aj-stein-nist ?
Follow up question for @JustKuzya: is the "should look like" model sketch above showing the JSON schema produced by oscal-cli, by some other tool, or a correct design by 'dead reckoning'?
Any answer is fine, and aligning with oscal-cli is especially fine.
@JustKuzya won't choice
translate into a JSON Schema oneOf
?
But I am getting ahead of us. It is not really worth discussing until we have working and breaking examples of actual JSON.
Behind https://github.com/usnistgov/metaschema-xslt/pull/108 there is WIP towards supporting choice
.
It also exposes the difficulty here*, namely a combinatorial explosion of subschemas to be listed under oneOf
, when choices proliferate. For each choice
offered in any model, we get as many subschemas as there are choices, and sibling choices are compounded, i.e. we get the cross-product. So if a model has a choice of three followed by a choice of four, we need twelve (3x4) subschemas for it.
More research is called for. I would love extra eyes on this and suggestions are welcome: please comment or ping me.
* I was pretty sure there was a reason we did not implement this sooner.
As noted, significant work towards implementing (exclusive) 'choice' in metaschema-xslt JSON Schema production is now behind PR #108. This includes analysis and a solution for the 'expand model' step that rewrites options implied by choice
, as well as new and useful testing infrastructure. Work still needed:
Describe the bug
When using metaschema-xslt as of
7d9fbfa84e78e4ba4dd950ad39c65738b7b66697
and also tested off of current develop (at []()), Metaschema modules that define a<choice/>
are not correctly serializing the choice options correctly as one or N choices, but allowing any defined.Who is the bug affecting?
Tool developers relying on generated JSON schemas from this tool.
What is affected by this bug?
JSON Schema generation with models using
<choice/>
.When does this occur?
Consistently.
How do we replicate the issue?
Example model, current output, and desired outputs to follow in upcoming edits to this issue.
ajv
, or any other JSON Schema validator tool.JSON document instance:
Current JSON Schema:
Expected behavior (i.e. solution)
The generated JSON Schemas serialize
<choice/>
into a selection with JSON Schema'soneOf
syntax, notanyOf
.The target JSON Schema should look this:
Other Comments
N/A