# Possible error in AOM 1.4

**Category:** [ADL](https://discourse.openehr.org/c/adl/40)
**Created:** 2023-02-12 02:34 UTC
**Views:** 457
**Replies:** 7
**URL:** https://discourse.openehr.org/t/possible-error-in-aom-1-4/3559

---

## Post #1 by @pablo

https://specifications.openehr.org/releases/AM/Release-2.2.0/AOM1.4.html#_c_multiple_attribute_class

In C_MULTIPLE_ATTRIBUTE invariants:

***Members_valid***: `members /= Void and then members.for_all(co: C_OBJECT | co.occurrences.upper <= 1)`


Then we have archetypes like:

				events cardinality matches {1..*; unordered} matches {
					POINT_EVENT[at0002] occurrences matches {0..*} matches {


a. events is C_MULTIPLE_ATTRIBUTE
b. POINT_EVENT is a C_OBJECT in the CMA.members and COBJECT.occurrences.upper is *, which violates the invariant


Not sure if I'm missing something here, though the invariant doesn't seem correct.

---

## Post #2 by @damoca

That seems an error, since it doesn't allow any occurrence bigger than 1.

At first I though maybe it meant to be a >:

`members /= Void and then members.for_all(co: C_OBJECT | co.occurrences.upper >= 1)`

But why would we want to technically avoid something like this?

    content existence matches {0..1} cardinality matches {0..*; unordered} matches {
        SECTION[at0001] occurrences matches {0..0} matches {*}  -- SECTION
        OBSERVATION[at0002] occurrences matches {0..*} matches {*}  -- OBSERVATION
    }


Could it be that that invariant should be be assigned to the C_SINGLE_ATTRIBUTE instead? There it could make sense, for defining alternative C_OBJECTS. Since we only can have one of them at the instances, we don't need to define any upper occurrence bigger than 1.

    ELEMENT[at0006] occurrences matches {0..*} matches {  -- ELEMENT
        value existence matches {0..1} matches {
            DV_BOOLEAN[at0007] occurrences matches {0..1} matches {*}  -- DV_BOOLEAN
            DV_TEXT[at0008] occurrences matches {0..1} matches {*}  -- DV_TEXT
        }
    }

---

## Post #3 by @thomas.beale

[quote="damoca, post:2, topic:3559"]
Could it be that that invariant should be be assigned to the C_SINGLE_ATTRIBUTE instead? There it could make sense, for defining alternative C_OBJECTS. Since we only can have one of them at the instances, we don’t need to define any upper occurrence bigger than 1.
[/quote]

I think that is probably right. Somehow this invariant ended up on the wrong class. In ADL2, there is only C_ATTRIBUTE, and no such invariant anyway. I will change this in the UML.

---

## Post #4 by @pablo

I agree the invariant is for SINGLE_ATTRIBUTE.

---

## Post #5 by @thomas.beale

I have fixed the UML extraction so that the AOM1.4 model is finally included in the UML site output. See https://specifications.openehr.org/releases/UML/latest/index.html#Diagrams___19_0_3_8fe028d_1676408399056_611261_6408

---

## Post #6 by @pablo

@thomas.beale about the UML correction, note the error is in the table invariants, not in the UML: https://specifications.openehr.org/releases/AM/Release-2.2.0/AOM1.4.html#_c_multiple_attribute_class

@thomas.beale @damoca 

I also detected something that might be missing:

When a C_SINGLE_ATTRIBUTE.alternatives().size() > 1, for all C_OBJECT in alternatives(), the C_OBJECT.occurrences.lower == 0

Because if any alternative has lower 1, it means that is the only alternative of object that can occur at that attribute (since it's a single attribute).

I can't find that constraint/invariant in AOM 1.4, and it's key for modeling tools, and for archetype/template validation.

What do you think?

---

## Post #7 by @damoca

I found the corresponding rule in the https://specifications.openehr.org/releases/AM/latest/AOM2.html#_validity_rules_c_attribute specifications

![image|690x78](upload://wC5shUqfVCd36zU398ILfA9wCaC.png)

---

## Post #8 by @damoca

[quote="pablo, post:6, topic:3559"]
I also detected something that might be missing:

When a C_SINGLE_ATTRIBUTE.alternatives().size() > 1, for all C_OBJECT in alternatives(), the C_OBJECT.occurrences.lower == 0
[/quote]

That's what we validate in LinkEHR Studio:

![image|690x224](upload://syWT2zWKXe6SP1zt1gplnYfLufU.png)


However, now that I think about it, I have some doubts. From a purely technical approach it seems a valid rule since, otherwise, in the instances only one of the children C_OBJECT would be compliant with the archetype.

But if we look at the context, (i.e. we are defining an alternative inside a C_SINGLE_ATTRIBUTE) defining those lower occurrences to 1 is as good as saying that a C_SINGLE_ATTRIBUTE has two possible children, when that will never happen in the instances. Moreover, if we could not use those {1} occurrences, how would we constrain that an ELEMENT cannot be null? They only way to do that is by defining that the alternatives, which are exclusive, have a minimum occurrence of 1.

I believe that the second interpretation is the correct one.

---


**Canonical:** https://discourse.openehr.org/t/possible-error-in-aom-1-4/3559
**Original content:** https://discourse.openehr.org/t/possible-error-in-aom-1-4/3559