Archie v3.2.0
What's Changed
- CAttributeFlattener restore old behaviour behind config by @MattijsK in #489
- Warning: v3.1.0 unintentionally introduced new (correct) behaviour in flattening specialized archetypes. Before v3.1.0 it was possible to exclude an object (e.g.
CLUSTER[id5]occurrences matches {0}) before specializing it (e.g.CLUSTER[id5.1] matches...). Cluster 5.1 would still appear in the flattened archetype. The specification clearly says that an exclusion should always appear at the end. The in v3.1.0 introduced behaviour applies this and removes specialized objects after excluding the parent nodes when flattening. - v3.2.0 reverts this correct behaviour to the pre-v3.1.0 behaviour. It introduces a config variable for this:
FlattenerConfiguration.allowSpecializationAfterExclusion. WIthin this major version of Archie, the default will be set totrueas setting this to false is in theory backwards incompatible. - The ArchetypeValidator now adds a warning to the validation result in all cases where this configuration parameter would make a difference: when validating a specialized archetype with a node with
occurrences matches {0}, with the node id equal to that in the parent, followed by a specialization of that node in the specialized archetype.
- Warning: v3.1.0 unintentionally introduced new (correct) behaviour in flattening specialized archetypes. Before v3.1.0 it was possible to exclude an object (e.g.
Example of such a case:
CLUSTER[id5] matches {
items matches {
ELEMENT[id8] occurrences matches {0}
ELEMENT[id8.1] matches {
....
}
}
}
The fix is changing the order of the id8 and id8.1 statements, as specified as being the only correct order to do so in the ADL 2 specification in https://specifications.openehr.org/releases/AM/latest/ADL2.html#_exhaustive_and_non_exhaustive_redefinition . The warning has been added because according to that same specification, it is incorrect to do this in another order.
The problem was introduced with a fix in the flattener with problems with sibling order (#477) . Disabling or enabling this configuration parameter does not impact this fix - in both cases the issues fixed there will no longer be present in version 3.2.0
Full Changelog: v3.1.0...v3.2.0