Allow regularly structured primitive objects.

Description

In the current version of ADL and the AOM, primitive objects can only be represented using inline constraint syntax, as per this part of the spec: https://specifications.openehr.org/releases/AM/latest/ADL2.html#cADL_Constraints_Primitive_Types

However, there is sometimes a need to constrain an RM attribute statically typed to e.g. Any or similar, to a particular Primitive type, without stating any constraint on the value.

Doing this would require the 'regular' object structure syntax, so that a type name could be expressed. Doing that requires a proper id-code.

The requirement originally came from HL7 CIMI, where they use the Terminology_code (named 'Concept' in their RM) as the type of various attributes, and want to constrain just the type in a parent archetype and then lower down the specialisation hierarchy, add concrete constraints. Currently the flattener will not allow this.

Activity

Show:

Thomas Beale March 13, 2021 at 1:39 PM

I’ve now improved the text in AOM2 indicating that C_Primitive types don’t always have the default primitive node_id code id9999; also improved the text describing the relation between assumed primitive types and C_Primitive constrainer types.

The question of cardinality of primitive constrainers is difficult to solve 100% correctly, because UML simply can’t represent the idea that an attribute whose type is List<T> requires the List to be there, but it may be empty. I had 1..* as the cardinality before, but in subtypes of C_Primitive_object I’ve changed it to 0..* and documented with the following 'To represent no constraint, use an empty list.'

See most recent commit.

Thomas Beale March 12, 2021 at 11:39 PM

I am getting through your earlier detailed list - just fixed a UML extractor problem that generated Interval<Integer> instead of List<Interval<Integer>>.

Pieter Bos March 12, 2021 at 1:35 PM

with the clarification above, I feel ok to accept this, even though I do not think this will be a often used or supported feature.

Thomas Beale March 10, 2021 at 8:11 PM

My aim is to get the grammar ‘clean’ and then one of us writes that script - I do actually want to get a CamelCase version done but I’d rather it was fully CamelCase, not just a few bits. I’ll check on the operator precedence and see if I can improve anything there. More soon…

Pieter Bos March 10, 2021 at 8:05 PM

for the rules grammar, there are many things that can be improved. Operator precedence is incorrect for I think the not operator, and it is written antlr3 style - because the original was lacking precedence at all, and I did not know the antlr-4 way to do this back then.

 

Plus of course the CamelCase naming convention, but I haven’t gotten to writing a script to fix that…

Done

Details

Reporter

Raised By

Thomas Beale

Original estimate

Affects versions

Created January 4, 2018 at 7:48 PM
Updated March 13, 2021 at 1:39 PM
Resolved March 13, 2021 at 1:39 PM
Loading...