Allow regularly structured primitive objects.
Description
Activity
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
@Pieter Bos 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…
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.