behaviour in choice assembly has changed

[wandmagic]

Describe the bug

choice assembly causes strang behaviour.
when I run oscal-cli metaschema-validate on a poam on-date and within date range choice, expects a cardinality of one for both objects, which is impossible.
I was able to fix it by leveraging choice group, but I think for backwards compatability we want choice to work in a mutual exclusive matter.
See this test run
https://github.com/GSA/OSCAL/actions/runs/11972676033/job/33380075445

Who is the bug affecting

OSCAL developers

How do we replicate this issue

check out linked repo and run make configure && make test

Expected behavior (i.e. solution)

poam should be valid when running oscal-cli metaschema validate-content <valid-poam.xml>

Other comments

I originally thought this was a bug in OSCAL metaschema itself, and maybe it is and we need to update to choice group? kindly let us know

[aj-stein-gsa]

@david-waltermire I pointed out that I presume this is an error in metaschema-java processing because these are both inline definitions in separate assemblies in the same model, not global, and Metaschema specific this is not a collision right?

They are in finding and risk assemblies, respectively.

https://github.com/usnistgov/OSCAL/blob/v1.1.2/src/metaschema/oscal_assessment-common_metaschema.xml#L830-L839

https://github.com/usnistgov/OSCAL/blob/v1.1.2/src/metaschema/oscal_assessment-common_metaschema.xml#L1296-L1305

[david-waltermire]

I believe the problem is here. This should not be the static value 1, but should instead be 0 if all child assemblies allow 0 or 1 otherwise. This change should adjust the schema generation behavior as well.

I think I can work up a test case from here.

[david-waltermire]

@david-waltermire I pointed out that I presume this is an error in metaschema-java processing because these are both inline definitions in separate assemblies in the same model, not global, and Metaschema specific this is not a collision right?

They are in finding and risk assemblies, respectively.

https://github.com/usnistgov/OSCAL/blob/v1.1.2/src/metaschema/oscal_assessment-common_metaschema.xml#L830-L839

https://github.com/usnistgov/OSCAL/blob/v1.1.2/src/metaschema/oscal_assessment-common_metaschema.xml#L1296-L1305

These references don't appear to be choices.

I am trying to reproduce the error, but I am having no luck doing so.

@wandmagic Can you help me by pointing me to a choice that is not working? Better yet, can you provide a standalone Module and content that illustrates this problem?

[wandmagic]

run this command
npx oscal-cli metaschema validate-content -m https://raw.githubusercontent.com/usnistgov/OSCAL/refs/heads/main/src/metaschema/oscal_profile_metaschema.xml https://raw.githubusercontent.com/GSA/fedramp-automation/refs/heads/develop/src/validations/constraints/content/fedramp-tailoring-profile.xml
and then run this command:
npx oscal-cli validate https://raw.githubusercontent.com/GSA/fedramp-automation/refs/heads/develop/src/validations/constraints/content/fedramp-tailoring-profile.xml
these two commands SHOULD have the same behaviour

[wandmagic]

this is not yet fixed as of 2.4.0 snapshot:
see this unit test run
https://github.com/wandmagic/OSCAL/actions/runs/12016300978/job/33496200751

[wandmagic]

npx oscal-cli metaschema validate-content -m https://raw.githubusercontent.com/usnistgov/OSCAL/refs/heads/main/src/metaschema/oscal_profile_metaschema.xml https://raw.githubusercontent.com/GSA/fedramp-automation/refs/heads/develop/src/validations/constraints/content/fedramp-tailoring-profile.xml

this example now works with latest build!

the poam issue must be a different issue