Following the extensive discussion in SPECAM-71, I am posting here, to be more visible.
Technically speaking, i.e. according to the current spec, a single-valued attribute is ‘open’ in the same sense as a multiply-valued attribute, such that a child archetype may add (extend) with new constraint objects, as long as they don’t violate the relevant RM attribute, i.e. ELEMENT.value: DATA_VALUE, in this case.
In both cases, some new object constraint could be added in a child archetype that doesn’t specialise those already in the parent, but is added de novo; it could then be the case that the data created according to that child archetype uses only that new object constraint (assuming all the others were optional / 0..*). Then the data won’t appear to conform to the parent archetype, but in fact it does, because the meaning of the parent archetype attribute constraint is: any of these items OR any other object that is allowed by the reference model.
Some runtime implementations probably don’t implement this OR condition because most archetypes and data don’t function like this.
Note that there is a much more common situation where extension in a specialised archetype is needed - which is simply the addition of an extra node (some extra datum in a lab panel or whatever) that is used AS WELL AS the existing data items; the local application knows to expect the N+1 data items; more general applications made elsewhere that see this data just don’t see that +1 data item, and don’t care.
So the application failure that @pieterbos describes is in fact because the application (probably like many others) doesn’t implement this ‘back-door’ condition. Technically speaking, the application is faulty, but the problem is that it is built following intuitive (and statistically mostly safe) expectations.
Now, we could change the redefinition / extension rule to be the other way, such that for both multiply- and singly-valued attributes, once some child object constraints had been stated, only pure redefinitions of those are allowed UNLESS some specific flag were set on the attribute like ‘non-exhaustive’ or whatever.
The problem here is that archetype designers have to consciously decide to set that flag. Mostly they will say - well, who knows what could happen, we’ll set that flag’ - and we are back to the current rules.
SLIGHTLY RADICAL SOLUTION
The only way out of this I have found (which I thought of years ago, but never took it anywhere) is to enable an ‘extension mode’ to be set on the whole of the archetype. The idea is that the rules you want to apply are the ‘open’ rules for widely used archetypes (CKM, national level etc), but for local development, you want to specialise some CKM archetype, turn off extension, and just do pure redefinition (which still allows you to do things like turn a DV_TEXT into a DV_CODED_TEXT, since that is RM-legal inheritance). It might be that in ADL2 template overlay archetypes, we could default to ‘no extensions, pure constraint’. Once you turn off extension in an archetype, no child archetype could turn it back on again.
This could even be done by the use of variant keywords for ‘specialise’, e.g. ‘constrain’ could be defined to ‘specialise, with no extensions’.