has-cardinality doesn't work as intended without @test

[aj-stein-nist]

Describe the bug

I discovered this when completing a tutorial for #554 and attempting to build representation models.

In the current version of the Metaschema syntax of the has-cardinality constraint, two has-cardinality constraints that query exclusive sequences in different document instances cannot be defined in the same model. In this case given a mutually exclusive @target when it is true for document instances the constraint will pass as valid and for false for others, and not be ignored when the @target does not match.

Examples are provided below in how to reproduce the bug.

I recommend we add @test to match other syntax and semantics of other constraint types to support this behavior.

Who is the bug affecting?

Developers of information models that need conditional logic processing of similar has-cardinality constraints, but with different min-occurs and max-occurs that cannot be satisfied optionally.

What is affected by this bug?

Processing of has-cardinality constraints.

When does this occur?

Consistently

How do we replicate the issue?

Use the following Metaschema module and samples.

When only two items with @grouping='two-only-group' constraint with @id='three-only-group fails even if @target
doesn't match.

When only three items with @grouping='three-only-group' constraint with @id='two-only-group fails even if @target doesn't match.

Expected behavior (i.e. solution)

The min-occurs and max-occurs properly trigger conditionally for one constraint and the other based on test evaluation, but not both so one always fail.

Other Comments

Per preliminary discussion with @david-waltermire, I am opening this issue for discussion and review with maintainers and community adopters in an upcoming meeting.

[aj-stein-nist]

In today's community call, we revisited this bug and did agree there is some gap in consistency around the how the has-cardinality constraint type. For one example, it is not consistent with expect and other constraint types.

When discussing and reviewing the examples, we can understand, by metaphor, that constraints like this constraint and some (but not all) constraint types have a notion of "subject" and "objects" of a constraint, much like natural language, to what are you constraining and how we constrain it respectively. We agree this is an important metaphor to use in upcoming documentation pertaining to these changes given pending work described below.

Moving forward, we agree we should 1) enhance has cardinality to add a new attribute to capture that missing "object" definition (because the currently existing @target, with the current name or a new alternative, is that "subject" definition) and 2) we should support backwards-compatible functionality where the implied object definition focus for the one-style attribute used by OSCAL and other Metaschema modules implies the value of the current evaluation focus (="." in Metapath parlance; this implied style is very much in consistent style and practice with other Metaschema constraints).

@david-waltermire, @wendellpiez, or others let me know if I missed something or misconstrued it.

[wendellpiez]

Let's say the 'object' flag is called counting --

To confirm, as I understand it this stipulates that where the old syntax appears (missing counting) it can implicitly be rewritten, so

<has-cardinality target="EXPR" mix-occurs="3" max-occurs="5"/>

becomes

<has-cardinality target="." counting="EXPR" mix-occurs="3" max-occurs="5"/>

Indeed I was hoping that this could work out if we simply stated the default of counting should be taken to be ., but that doesn't quite work. (Because finding a bunch of things and then counting them from there just gets a bunch of ones.)

But indeed, this makes this constraint more like the others, a good thing.

[iMichaela]

@wewndell - Are you familiar with this issue? Do you have a test for it? To me it appears the bug was never fixed and the PR #554 addressing issue #545 has been abandoned.
Please advise. Thank you.

[wendellpiez]

There is no bug here.

The only implementation currently in the field (tmk) for the has-cardinality constraint is in the oscal-cli tool (although I don't know the status of that repo). I have a prototype implementation in an experimental tool (more info on request), but as we are not distributing or offering to support that, I don't consider it in scope here. (It has tests but it needs to be tested further, in the context of deployment, by other hands than mine.)

The semantics of has-cardinality are defined here:

https://pages.nist.gov/metaschema/specification/syntax/constraints/#has-cardinality-constraints

If/when OSCAL-CLI is no longer conformant to this specification (perhaps preferring another one under more active maintenance), presumably they have stated that (or rather, they point to a spec to which they do conform), in which case this becomes an oscal-cli question (how does the feature work there?) or an "academic" one (since we otherwise do not support the feature). To the extent this might (now or someday) warrant syntax changes in updated OSCAL models is an OSCAL question.

If the OP or any users prefer to propose changes to the current design - it would entail both a new schema for the Metaschema, and updates to the docs - that is properly done via a PR. (However if they have already moved off this schema/docs, they may not want to bother.)

@david-waltermire @aj-stein-nist please offer any qualifications, corrections or caveats to what I have just stated? (In particular, my links might be stale if work has moved off NIST repositories?)

Random observation: IMV the deeper problem of which this problem is a symptom will never be remedied by multiple implementations chasing one another's tails, but by a community-backed and -built set of tests showing both typical and edge cases. Without a library of tests we can share, and which can be validated externally by friends and adversaries, all else is thrashing. I know you folks who know me can hear the song looping here.

We need two such libraries: one test library for the metaschema (or equivalent back end) supporting the design of its supported constraints model (syntax and semantics); and one test library for OSCAL, for testing the design of OSCAL constraints specifically.