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.
GG: yes, the problem is the confusion we have between the cardinality of the attribute and the cardinality of the collection inside the type.
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:
GG: this analysis is all screwed up. Most of these constraints are illegal. You can constrain something to something more specialised, not less, or by it's demotion or promotion. So, for instance, you cannot constrain GTS to SET<IVL<TS>> but only to LIST<IVL<TS>>, though the same issue still applies here
- 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>.
--Lmckenzi 18:16, 6 Jun 2006 (CDT)
