Currently existence, occurrences and cardinality are all mandatory in the AOM. However, with reference model checking, this is not required. Existence and cardinality should only be stated when they override, i.e. narrow the reference model value. Occurrences should only be stated when it overrides the RM cardinality for multiply-valued attributes, or existence, for single-valued attributes. E.g. if the cardinality for a multuply-valued attribute is 0.., then the occurrences will be assumed to be 0.. on each member Object in an archetype unless otherwise stated.
While you can infer the cardinality restraint from the occurrences of the contained objects this is not required unless there is a forcing of choice. So a cluster with cardinality of 2..2 and three elements with 1..1, 0..1, 0..1 will force a choice between the 2nd and 3rd elements. At present this is the only way to force a choice in openEHR.
What is important to recognise is that limiting the cardinality in an archetype for a container is usually not helpful as it may cause problems with future revisions.
Agreed. But the ability to override cardinality for other reasons is still needed, even just to redefine from 0..* to 1..*. To support a proper notion of 'selection', there is a proposed 'select' constraint described on the openEHR wiki at http://www.openehr.org/wiki/display/spec/Ordering+and+choice+in+archetypes+and+templates
So it will be retroactive? Take also into account that this will make the parser RM dependent.
I'm assuming we will stick to the idea of issuing interim specifications from 1.4.2, i.e. 1.5, 1.6 etc.
The parser doesn't have to be RM-dependent, but one phase of validation needs to be. If there is no checking against an RM, it's probably not really an archetype...