RIM Cardinality issues

Issue

I was doing some playing with a v3 model and came across something I can't believe we haven't run into before this.

One of the allowed specializations of GTS is SET<IVL<TS>>, which effectively means that I can constrain GTS in my model to be SET<IVL<TS>>. However, when I do so, the cardinality is still constrained to 1..1. That's because the cardinality in the RIM is 1..1.

Obviously, this is a problem.

We already solved this issue for ANY (when we realized it could also be constrained to SETs, BAGs and LISTs). This example shows the problem is much more widespread.

Doing a quick analysis, it occurs for the following datatypes:

• ANY -> LIST, BAG or SET
• CAL ->SET<CLCY> (though I doubt we care)
• GTS -> SET<TS>
• IVL<x> -> SET<x>
• HIST<x> -> SET<HXIT<x>>
• NPPD<x> -> SET<UVP<x>>
• PIVL -> SET<TS>
• EIVL -> SET<TS>
• BIN -> LIST<BN> (again, unlikely to care)
• AD -> LIST<ADXP>

What's really happening here is that the datatype has an implicit cardinality within it. I.e. when you reference a GTS, the datatype itself contains an implicit reference to SET<TS> with a cardinality of 0..* (as all abstract datatype cardinalities for LIST, SET and BAG properties have no upper bound.) When we constrain GTS to SET<TS>, we're effectively exposing this internal datatype 'property' cardinality up to the attribute layer.

Recommendation

My recommendation is we change the methodology to explicitly acknowledge that changes such as 1..1 GTS to 1..* SET<TS> in fact constitutes a constraint. I.e. You cannot evaluate whether a change in upper bound cardinality is, of itself, a constraint or extension without also looking at the change of datatype.

The more general rule is as follows: If a non-collection datatype can be constrained to a collection datatype (SET, LIST, BAG), then the base upper cardinality for purposes of determining constraint shall be considered to be the cardinality of the derived type in the derivation relationship between original type and the derived type. Generally this will be "unlimited", though datatype flavors may impose more constrained limits.

E.g. If GTS.UK is constrained to be an intersection of a maximum of 3 IVL<TS> types, then 0..1 GTS.UK could be constrained to 0..3 IVL<TS>.

Discussion

Comment from Grahame: There are three key problems here:

• We have confusion between the cardinality of the attribute and the cardinality of the collection inside the type. To be consistent, we'd make every attribute have a cardinality 1.1; after all, the attribute is always present, just sometimes it has a nullFlavor of NI. And we would define multiplicity constraints on the datatype properties directly using some formalism yet to be invented (or a language like OCL). We should do this.

• Also, there is total confusion about what can be constrained to what. All but one of Lloyd's proposed constraints are illegal. The mere fact that they are allowed by the tools, widely practised, and based on solid conceptual grounds doesn't mean that they are actually allowed by the the abstract datatypes specification. This particularly applies in the GTS area. I will review this as part of data types R2.

• The third is the conflation of 2 different concepts, specialising for functionality and applying a pattern of constraint. They're similar - but not quite the same.

Resolution

From Sept., 2006 WGM:

Datatypes R2 and the new tooling suite will adjust the handling of cardinality as follows: - Cardinality will be a characteristic of the type declaration rather than the attribute. Attributes and datatype properties will not have cardinalities. When referencing a collection datatype such as SET, LIST or BAG, the desired cardinality range of the contents of the collection will be declared as a static part of the type reference.

E.g. SET[1..5]<PQ>

In addition, a new characteristic will be supported for attributes and properties (Lloyd: and possibly associations?) that indicates whether the element must be "populated" in an instance. Being populated means that the element must be present, either with a value or a null flavor.

Finally, the ITS will be revised to allow clearly distinguishing null flavors which apply to the entire attribute, vs. those which apply to an element within a collection.

Actions

Changes to Datatypes, HDF, tooling and ITS to reflect the above