Make DATA_VALUE inherit from LOCATABLE

Yes, I think domain type constraints were created as a shortcut for the ADL notation but added extra complexity to the archetype/template/data processing and, as you noted, some modeling side effects.

also as a note on domain types, I’ve seen already several people create DV_Quantities domain types in AD with lists of units thinking they are defining unit alternatives not being aware of the implications of using domain types

Diego is right! I didn’t said it correctly, the way we deal with “the problem in AOM 1.4” should have been “the problem in the RM when using AOM 1.4”. Sorry for the noise, just wrote that too fast.

The issue is not having a place to store the node_id that appears in AOM 1.4 on the current RM at the DATA_VALUE level. Then when you process data, for the DVs you don’t know exactly to which AOM node it corresponds, so you need to make lookups by the attribute names or the object type to find a constraint alternative in the AOM for that DV object in a RM instance.

PS: I also would be happy to get rid of the domain types since the same could be modeled with the standard constraints model and just break the processing patterns of the constraints when developing (instead of just using recursion for the whole tree you need to add IFs for the domain types and process them separately). People that wrote data validators using AOM/TOM will know what I’m talking about

It is not really in issue in AOM1.4, the C_PRIMITIVE_OBJECT inherits from C_OBJECT, which has indeed a node id attribute. Problem is that DATA_VALUE has no place to store them. Hurts in validation and transformation (you probably need to have different transformations depending on the alternative), and actually makes one of the typical examples in openEHR (two quantities alternatives with different ranges for different units) impossible to actually validate. This problem is not more evident because domain types are a thing, but the standard equivalent of a domain type is not as straightforward as one could think (and could be).

In summary, AOM has no problem with it and just an optional node id would make things work, no need to put names, links, feder_audit at that level.

I would be interested on discussing how implementations deal with the issue. I don’t have data to say it’s a marginal real world problem, maybe implementers and just creating their own workarounds as I did to reference a specific alternative, for instance, in an ELEMENT.value constraint.

I believe the most common way to deal with this problem in AOM 1.4 is by checking attributes present or the data type itself, though this adds a modeling constraint which is having alternative constraints of the same type, which is impossible to do today in AOM 1.4. In general I think this is a real problem, that is not solved by the specs, and that implementers tend to find workarounds.

My personal opinion is that this is a design flaw in the specs themselves, and hope we can have all this sorted out with openEHR RM v2.0 + AOM v3.0. I would ask more people to comment on the problem itself (having a path that points to a specific constraint in AOM) and how they solve this issue.

A side note, this will help to have type checking in AQL for detecting errors in AQL at design time.