Clarify rule for adding node with a different type under a single valued attribute
Description
Activity
Thomas Beale January 28, 2021 at 5:04 PM
I added a response here on Discourse, since we are now discussing a core semantic of ADL… I suggest we continue the discussion there, to be more visible to the wider group (also not to forget where it is).
Diego Bosca January 28, 2021 at 2:37 PM
It isn’t different to adding new terms to a valueset, and should also be discouraged
(a valueset is just N alternatives of non mandatory elements of the same type with all fields constant)
Ian McNicoll January 28, 2021 at 2:26 PM
“For adding a new field to a container attribute, yes. Adding a new choice of datatypes to a single valued attribute? probably major.“
So, I disagree but I think that is the core of the issue. My understanding that the heart of the version rules was that a major version change was required if it would invalidate existing data (e,g mandation enforced), or cause existing data to be unlocatable (path change, deleted element etc).
I still don't understand why adding an additional allowed datatype to an element is fundamentally different from adding a new term to a valueset - yes in both cases, a system that only expects a single datatype, or is not expecting a new term, may run into problems. I always teach people that this has to be managed as part of the artefact governance process e.g applying stricter constraints on templates to ‘remove’ the optionality, until such time as any apps are safe, and this is a big part of clinical safety testing. Exactly the same applies with external valuesets. This is not an openEHR issue . I think we can do better with tooling/package management to facilitate this process but I think it is (or should be!) well understood.
Pieter Bos January 28, 2021 at 2:18 PM
Ok, you get this archetype:
'hey, there will be a duration here!'
And you get this data:
'hey, I put a coded text here for you'
ANY validator validating against the parent archetype will now give a validation error. this is NOT valid data against the parent archetype.
I understand the modelling concerns, but this is simply not a solution, unless in short term cases where you plan on updating the parent archetype with a new version, and it should be a major version.
Pieter Bos January 28, 2021 at 2:17 PM
“Completely agree if we are removing any existing allowed datatypes but if we were to extend the range of datatypes in the parent, this would not (I hope) be a minor revision?”
For adding a new field to a container attribute, yes. Adding a new choice of datatypes to a single valued attribute? probably major.
Details
Details
Reporter
Pieter BosRaised By
and I recently found the following issue:
Given the following parent archetype:
Is it allowed to add a BOOLEAN data value in a specialized archetype, so as follow?
Both the ADL workbench and Archie accept this - and they probably should. But the AOM 2 specification contains the following text:
VSONCT specialised archetype object node reference type conformance: the reference model type of a redefined object node in a specialised archetype must conform to the reference model type in the corresponding node in the flat parent archetype by either being identical, or conforming via an inheritance relationship in the relevant reference model.
Then in https://specifications.openehr.org/releases/AM/latest/ADL2.html#_redefinition_concepts it defines adding a node as a redefinition. That combination would make it illegal to add a node in certain situations - depending on the definition of 'corresponding node'. I would say there is no corresponding node in the parent. But then the redefinition concepts text reads, under ADDING a node:
Differential node has a specialised node identifier, and corresponding node in flat parent has max occurrences > 1.
Which implies there is one. So I had a discussion with , and Thomas and I propose the following changes:
update the text under redefinition concepts under ADDING a note, removing the text ', and corresponding node in flat parent has max occurrences > 1'
add the above example in the ADL 2 specification, perhaps including the flat form: