RIM Cardinality issues

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.

What to do: 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>.

-- Comment from Grahame: --

There is a two 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.

--Lmckenzi 18:16, 6 Jun 2006 (CDT)