Examples for usnistgov/metaschema#559

condtional_has-cardinality_559_instance-1.xml

<?xml version="1.0" encoding="UTF-8"?>
<foo xmlns="https://github.com/usnistgov/metaschema/issues/559">
    <bar grouping="three-only-group">a</bar>
    <bar grouping="three-only-group">b</bar>
    <bar grouping="three-only-group">c</bar>
</foo>

condtional_has-cardinality_559_instance-2.xml

<?xml version="1.0" encoding="UTF-8"?>
<foo xmlns="https://github.com/usnistgov/metaschema/issues/559">
    <bar grouping="two-only-group">a</bar>
    <bar grouping="two-only-group">b</bar>
</foo>

condtional_has-cardinality_559_metaschema.xml

<?xml version="1.0" encoding="UTF-8"?>
<?xml-model href="https://raw.githubusercontent.com/usnistgov/metaschema/develop/schema/xml/metaschema.xsd" type="application/xml" schematypens="http://www.w3.org/2001/XMLSchema"?>
<METASCHEMA xmlns="http://csrc.nist.gov/ns/oscal/metaschema/1.0">
    <schema-name>Model for conditional has-cardinality modeling for usnistgov/metaschema#559</schema-name>
    <schema-version>0.1.0</schema-version>
    <short-name>conditional-has-cardinality-559</short-name>
    <namespace>https://github.com/usnistgov/metaschema/issues/559</namespace>
    <json-base-uri>https://github.com/usnistgov/metaschema/issues/559</json-base-uri>
    <define-assembly name="foo">
        <formal-name>Root Assembly</formal-name>
        <description>The fields of this assembly should count either on two-only-group or three-only-group.</description>
        <root-name>foo</root-name>
        <model>
            <define-field name="bar" as-type="string" min-occurs="1" max-occurs="unbounded">
                <formal-name>Bar Units</formal-name>
                <json-value-key>value</json-value-key>
                <group-as name="bars" in-json="ARRAY"/>
                <define-flag name="grouping">
                    <constraint>
                        <allowed-values allow-other="yes">
                            <enum value="two-only-group"/>
                            <enum value="three-only-group"/>
                        </allowed-values>
                    </constraint>
                </define-flag>
            </define-field>
        </model>
        <constraint>
            <has-cardinality id="only-two" level="ERROR" target="bar[@grouping='two-only-group']" min-occurs="2" max-occurs="2"/>
            <has-cardinality id="only-three" level="ERROR" target="bar[@grouping='three-only-group']" min-occurs="3" max-occurs="3"/>
        </constraint>
    </define-assembly>
</METASCHEMA>

Also of note: here is a sample that passes the test as given, which is actually not self-contradictory

Excellent point and I didn't even cover this in the issue or my example. You can make more elaborate use of @target or another equivalent to @test if that existed to make sure it is of only that kind or fail.

Regarding expect and how all of them are designed, we could replace everything with <expect/>. However, that leads to some very clunky Metapath (for model developers to write or for upstream Metaschema processors to implement out the gate) for realistic use. At that point, I would argue <allowed-values/> or <index/> could go, but the progression ladder allows more junior people to have expressive power for simpler use cases without writing up advanced Metapath.

Now regarding this progression of difficulty with Metapath and this decision, maybe we can talk about that here or in the issue: is that a hard requirement or just a nice to have? It seems almost of the constraint system is designed for it to be more than a nice to have, and it is a hard requirement to make easier use cases easier for model developers to use at the expense of (understandably) harder to implement for the processor devs, but this point is not lost on me.