# Concrete DATA_VALUE type for an ELEMENT with multiple objects

**Category:** [ADL](https://discourse.openehr.org/c/adl/40)
**Created:** 2022-01-18 10:23 UTC
**Views:** 669
**Replies:** 5
**URL:** https://discourse.openehr.org/t/concrete-data-value-type-for-an-element-with-multiple-objects/2268

---

## Post #1 by @borut.jures

I'm struggling with an ELEMENT that has a single "value" but multiple objects:

```
ELEMENT[id15] occurrences matches {0..1} matches {    -- Location of measurement
    value matches {
        DV_CODED_TEXT[id9024] occurrences matches {0..1} matches {
            defining_code matches {[ac9006]}    -- Location of measurement (synthesised)
        }
        DV_TEXT[id9025] occurrences matches {0..1} 
    }
}
```

From the above ADL my code generator cannot figure out the type of the concrete DATA_VALUE type of the "value" attribute.

"id9024" and "id9025" are not defined in the OPT ("openEHR-EHR-OBSERVATION.blood_pressure.v2.0.8.opt2"). Many other OPTs are using the same two ids and they are never defined. Are they defined somewhere else?

Even looking at the ADL grammar doesn't help.

I understand why it is modeled the way it is but can somebody please help me with a way to pick the correct [DATA_VALUE type](https://specifications.openehr.org/releases/RM/latest/data_types.html#_data_value_class) for the above "value" attribute?

---

## Post #2 by @pablo

This is a specification for allowed alternative types. It constraint the possible subclasses that could appear at that point and constraints on those classes.

---

## Post #3 by @thomas.beale

As @pablo says, you have to remember an archetype is always a constraint on possibilities. So even for a single-valued attribute like ELEMENT.value, there can be more than one alternative. [The ADL2 spec explains](https://specifications.openehr.org/releases/AM/latest/ADL2.html#_single_valued_attributes).

To go a bit further, the *possible* objects defined in both single-valued and multiply-valued attributes are really just alternatives - it's just that in a multiply-valued attribute, you can have more than one of them at runtime, whereas for a single-valued attribute, you can have only one.

In terms of code generation, you probably need to generate a alternatives chooser combined widget of some kind.

---

## Post #4 by @borut.jures

Thank you Pablo and Thomas!

Your answers helped me understand how to implement this.

---

What follows is just my thoughts in case somebody else in the future stumbles on the same.

I incorrectly assumed that single-valued attributes can only have alternatives with the same DV_... type (as in the example in the specifications).

[quote="thomas.beale, post:3, topic:2268"]
it’s just that in a multiply-valued attribute, you can have more than one of them at runtime, whereas for a single-valued attribute, you can have only one
[/quote]

Without the above implicit rule about the single-valued attributes, the original example without occurrences looks like it allows ELEMENT to have DV_CODED_TEXT and DV_TEXT (both as is the case for multi-valued attributes). Now that I wrote the last sentence it is obvious that can't be the case - a single-valued attribute can only have a single value :man_facepalming:  That should be obvious to me.

The single-valued attributes can use a shorter syntax to express "only one" rule without a wrapper and the use of "occurrences".

---

The way I implement alternative types is to use an abstract class for the attribute type and then each alternative  implements that abstract type. This works for ITEM_TREE, CLUSTER,...

I can use the same approach with ELEMENT but I thought I could skip adding more intermediary classes for single-valued attributes.

![Screenshot 2022-01-18 at 15.36.12|640x500](upload://5llCFZXoINNs2aSpq8yXsiSXbjk.png)


---

In the case of DV_CODED_TEXT and DV_TEXT I could probably even skip the intermediary class but in the case of DV_CODED_TEXT and DV_CODED_TEXT both using their own "ac" value set the constraints wouldn't work correctly if they were both in a single class :thinking:

I'm incorrect again - the specifications cover this case: "Each block defines an alternative constraint, only one of which needs to be matched by the data."

---

I learned that implicit rules for syntax sugar are not expressed in the ANTLR4 grammar. You need to carefully read (and re-read) the specifications for humans too :blush:

---

## Post #5 by @borut.jures

It was a long day but single-valued attributes with alternatives are now handled by the generator :partying_face:
Thank you Pablo and Thomas for the helpful explanations!

---

The last class above is now an abstract class and each alternative value gets its concrete class with constraints:

![Screenshot 2022-01-18 at 23.16.33|584x499](upload://5L3GRqQIxuVehaBnFKCkryjAfvO.png)


p.s.
Nice short ADL syntax may cause a lot of extra work when writing a code generator :sweat_smile:

I wonder how the hand writen code handles these single-valued attributes with alternatives :thinking:

They are quite an edge case. At least in my case.

---

## Post #6 by @thomas.beale

Great work! I'm looking forward to having a closer look at the code, but I did read through this example - very interesting.

[quote="borut.jures, post:5, topic:2268"]
They are quite an edge case. At least in my case
[/quote]

In terms of domain modelling, they are very common - and indeed, are likely to be so in any domain, because that's how constraint modelling works - everything is possibilities, not just fixed data sets.

Onward and upward!

---


**Canonical:** https://discourse.openehr.org/t/concrete-data-value-type-for-an-element-with-multiple-objects/2268
**Original content:** https://discourse.openehr.org/t/concrete-data-value-type-for-an-element-with-multiple-objects/2268