-
-
Save aj-stein-nist/911b1a16dfaffd94cce01bb1ae08f479 to your computer and use it in GitHub Desktop.
| <?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> |
| <?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> |
| <?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.
So just to be clear, I made this example, that is generally silly, to illustrate a specific point without a lot more context in the computer model in usnistgov/metaschema#554 was a little more elaborate, I do not disagree there. This is the practical example where it was not very practical flag on the root assembly and the cross-referenced field is "higher up" in the tree of the node item. That is the model and example there.
{ "computer": { "id": "awesomepc1", "properties": [ { "ns": "http://example-consortium.org", "key": "release-status", "value": "public" }, { "ns": "http://specific-vendor.com", "key": "release-status", "value": "custom" }, { "ns": "http://example-consortium.org", "key": "release-date", "value": "2024-01-0Z" } ], "motherboard": { "vendor": { "id": "vendor2", "name": "ISA Corp", "address": "2000 K Street NW Washington, DC 20002", "website": "https://example.com/isacorp/" }, "type": "atx", "cpu": { "vendor": { "id": "vendor2", "name": "ISA Corp", "address": "2000 K Street NW Washington, DC 20002", "website": "https://example.com/isacorp/" }, "product-name": "Superchip Model 1 4-core Processor", "firmware": { "version": "1.2.1", "hash": { "algorithm": "sha512", "value": "7e9c54ef590b3e053495c253e135695eb55f4e966d49671e8739f5574d27f7809fefb8f75b998b1333a934bb59f4246928c11621e411286d77191a53ae362e3a" } }, "architecture": "arm64", "speed": "4.7 gigahertz" }, "ata-socket": { "vendor": { "id": "vendor2", "name": "ISA Corp", "address": "2000 K Street NW Washington, DC 20002", "website": "https://example.com/isacorp/" }, "product-name": "AwesomeSAS Model 1 Storage Socket", "type": "sas" }, "memory-modules": [ { "vendor": { "id": "vendor3", "name": "Massive Memory Corp", "address": "3000 K Street NW Washington, DC 20003", "website": "https://example.com/massive-memory-corp/" }, "product-name": "Erroneous Model 3 DDR4-3200 8GB (Module 1)", "size": { "count": 7, "prefix": "G", "unit": "B", "unit-system": "si", "base": "decimal" } }, { "vendor": { "id": "vendor3", "name": "Massive Memory Corp", "address": "3000 K Street NW Washington, DC 20003", "website": "https://example.com/massive-memory-corp/" }, "product-name": "Model 3 DDR4-3200 8GB (Module 2)", "size": { "count": 7, "prefix": "G", "unit": "B", "unit-system": "si", "base": "decimal" } } ] } } }Current source from WIP draft here
I do agree the above example is more contrived but there is a progression outlined in this tutorial, based on what I inferred from OSCAL before we wrote the spec for this constraint in usnistgov/metaschema#547, to document what was less clear than before. So I am just pointing out logically, the
@target/@testmechanism and how you can have rules adjacently meet different criteria (withexpect), regardless of how you name them, as you get up the ladder of understanding these, makes sense to me. As-is, discovering howhas-cardinalitywork without@testor whatever you decide to call it makes this incongruous with the others.