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 for the above “value” attribute?
This is a specification for allowed alternative types. It constraint the possible subclasses that could appear at that point and constraints on those classes.
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.
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.
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).
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
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:
Great work! I’m looking forward to having a closer look at the code, but I did read through this example - very interesting.
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.
That should be obvious to me.
