# Concrete DATA\_VALUE type for an ELEMENT with multiple objects
**URL:** https://discourse.openehr.org/t/concrete-data-value-type-for-an-element-with-multiple-objects/2268
**Category:** ADL
**Tags:** template
**Created:** [18 January 2022 10:23 UTC](https://discourse.openehr.org/t/concrete-data-value-type-for-an-element-with-multiple-objects/2268 "2022-01-18T10:23:35Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@borut.jures](https://discourse.openehr.org/u/borut.jures)
#### Post date: [18 January 2022 10:23 UTC](https://discourse.openehr.org/t/concrete-data-value-type-for-an-element-with-multiple-objects/2268/1 "2022-01-18T10:23:35Z")
I’m struggling with an ELEMENT that has a single “value” but multiple objects:
```auto
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?
---
### Author:  [@pablo](https://discourse.openehr.org/u/pablo)
#### Post date: [18 January 2022 12:27 UTC](https://discourse.openehr.org/t/concrete-data-value-type-for-an-element-with-multiple-objects/2268/2 "2022-01-18T12:27:39Z")
This is a specification for allowed alternative types. It constraint the possible subclasses that could appear at that point and constraints on those classes.
---
### Author:  [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [18 January 2022 14:06 UTC](https://discourse.openehr.org/t/concrete-data-value-type-for-an-element-with-multiple-objects/2268/3 "2022-01-18T14:06:40Z")
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.
---
### Author:  [@borut.jures](https://discourse.openehr.org/u/borut.jures)
#### Post date: [18 January 2022 15:05 UTC](https://discourse.openehr.org/t/concrete-data-value-type-for-an-element-with-multiple-objects/2268/4 "2022-01-18T15:05:59Z")
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).
> [@thomas.beale](#):
>
> 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
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 🤦♂️ 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.
* * *
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 🤔
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 😊
---
### Author:  [@borut.jures](https://discourse.openehr.org/u/borut.jures)
#### Post date: [18 January 2022 22:22 UTC](https://discourse.openehr.org/t/concrete-data-value-type-for-an-element-with-multiple-objects/2268/5 "2022-01-18T22:22:51Z")
It was a long day but single-valued attributes with alternatives are now handled by the generator 🥳
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:
p.s.
Nice short ADL syntax may cause a lot of extra work when writing a code generator 😅
I wonder how the hand writen code handles these single-valued attributes with alternatives 🤔
They are quite an edge case. At least in my case.
---
### Author:  [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [19 January 2022 01:54 UTC](https://discourse.openehr.org/t/concrete-data-value-type-for-an-element-with-multiple-objects/2268/6 "2022-01-19T01:54:53Z")
Great work! I’m looking forward to having a closer look at the code, but I did read through this example - very interesting.
> [@borut.jures](#):
>
> They are quite an edge case. At least in my case
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!