The way we handle cardinality is confusing and leads to modelling faults

[SimonCockx]

By reading an expression, it is often unclear whether it is singular or of multiple cardinality. This vagueness leads to problems in Rosetta models such as the CDM and DRR. Since the problem is deeply ingrained in the language, there are many examples to choose from, but I found the following example from the MAS regulation in DRR especially instructive.

The following rule, misleadingly called ContractForEvent, can actually result in multiple trades. This is because the attribute after is of multi cardinality (something which isn't clear when reading this), and after -> trade will implicitly map every TradeState to its corresponding Trade.

reporting rule ContractForEvent from ReportableEvent:
 	extract originatingWorkflowStep -> businessEvent -> after -> trade
 	as "Contract"

This results in more confusion down the line. For example, the following rule actually results in multiple booleans rather than a single one.

reporting rule IsInterestRatePayout from ReportableEvent:
    ContractForEvent then
    extract tradableProduct -> product -> contractualProduct -> economicTerms -> payout -> interestRatePayout only exists

The actual intention for the rule is probably to determine whether or not a single Trade represents a "interest rate payout", i.e.,

reporting rule IsInterestRatePayout from Trade:
    extract tradableProduct -> product -> contractualProduct -> economicTerms -> payout -> interestRatePayout only exists

Our current approach of designing the DSL was to try and hide technicalities of cardinality from modellers. However, as the example above illustrates, this can easily lead to a false sense of understanding what's going on, leading to more confusion and faults in the model in the long term.

Suggestions on improvements

I can think of five kinds of changes that will improve transparency and reduce modelling bugs. For each of them, I give a suggestion on how to fill it in, although further analysis is required to verify the best approach.

1. Be transparent about cardinality through the UI. For example, use syntax highlighting, a small inlay hint *, or cardinality info on hover to indicate when a modeller is working with attributes/expressions of multi cardinality.
2. Enforce explicit handling of multi-cardinality expressions. No implicitness. For example, remove support for using the path operator -> on expressions of multi-cardinality. Modellers should use extract instead.
3. Remove support for lists of lists. This additional layer of abstraction adds to the complexity of cardinality, without benefiting the expressiveness of the DSL. For example, enforce flattening (then flatten) right after an extract expressions that would result in a list of lists. Alternatively, consider joining extract and flatten together into a single operation (e.g., flat-extract).
4. Further include cardinality checks into the type system. (https://github.com/REGnosys/rosetta-dsl/wiki/Project:-DSL-Type-Formalisation) I wonder whether we should additionally differentiate between items/lists of the same cardinality (e.g., variable versus [variable] - both have a cardinality of (1..1)), or whether we should keep this conversion implicit.
5. Improve documentation on how cardinality is handled for different expressions, with examples.