I believe there was a Jira card raised for this issue to make it explicit in the RM that names do NOT need to be unique within a container, and Ocean proceeded to change their EHR libraries to allow this. I understand this has been resolved in ADL2. The cause of this problem was that in ADL1.4, we did not have any means to reference a constrained node other than using a name constraint. In order for templates to be implementable against the RM, not just logical, when a constrain was applied to the name attribute of a node, the maxOccurs for that name constrained (cloned) node was explicit changed set to 1.Īlthough this ensured templates would be implementable against this undocumented RM rule, it made logical modelling difficult where the name was constrained purely for labelling the node and not intended to constrain the occurrences. There is much history here, and from memory you are correct, there was always an undocumented rule that the name of a node needed to be unique within container. (as the various edits prove, I’m tired, so I’ll go have some tea now)
#Name of element city free
The most pragmatic thing for may be to follow other users and modify the tooling output, and also suggest to Better that their tool displays a warning that constraining the name will modify the cardinality as well ( 's suggestion as far as I can I suspect you have some valuable historical background for this, as usual, so feel free to educate me here. This is discussion to be had in the future in SEC. There are two ways the spec can clarify this ambiguity: at the RM level, or at the ADL (constraint) level. (I think) this is to ensure queries can fetch this data element Users are reportedly manually modifying the generated models to relax the cardinality constraint, therefore reverting the interpretation of the tools.ījorn’s users do not care about cardinality, they just need the element to have only one name.
Ocean template designer and Better’s Archetype Designer both modify the cardinality of an element in this case. Modelling tools however, interpret a constraint on a name as a constraint on its cardinality as well. There’s nothing in the openEHR specs that indicates that constraining the specificity of a name of an element should imply uniqueness of that element in terms of cardinality, if the element is under a type that allows anything beyond 0…1 I’m not sure if this is the kind of view you were expecting, but for what it’s worth this is mineīefore I forget, this is my take from today’s discussion (which took place elsewhere), kind of a set of meeting minutes: A constraint assigned to a string value of a property having side effects on cardinality does not sound right to me. I’d expect the latter to be the semantics of the constraint on the value of name. If the specificity of the value of the name means elements at this path can have only the following name, regardless of how many of elements may exist, then the tool’s behaviour is not correct.
there should be only one element at this RM path with name having this value, then the tool’s behaviour sounds correct. If we’re interpreting the the specificity of the value of the name as uniqueness, i.e. I think this depends on the interpretation of a constraint on the name of an element. As we understand this the name of the element is constrained to only allow a name like NEW_NAME_OF_ELEMENT, which in turn makes it impossible to repeat the element and still have it uniquely addressable with a path
0 kommentar(er)
