Theoretically, this could be solved by moving the “item-structure” package into the “common” specification. Or by creating a new specification for the commonly used types.
IMHO if it’s valid UML, the spec is perfectly fine.
In terms of implementation you can do any workarounds you need to comply with the technology you use. Note openEHR don’t define modules in a strict way, just packages. So if your preferred technology uses strict modules and can’t implement that dependency, one option is to not define those packages as different modules, the other option is to define some middle interface to break the dependency. There could be more implementation techniques to avoid issues. But the spec seems find to me.
Still, there’s the programmer’s intuition that something is wrong about cycles in software, in particular cycles that transcend the boundaries of one package. So you may want to fix them anyway.
For the record, I did rework the package hierarchy of the openEHR models some years ago to achieve strict uni-directional dependency relations. Those relations are true in this familiar diagram. This diagram shows ‘components’ which are outer packages.
Internal package relationships are supposed to follow this rule as well, but as you have pointed out, we broke the rule with the change you referred to.
It’s easy to fix, and the RM we have in Graphite Health puts the Data Structures in the BASE component, so they can be used by any other package.
However, @pablo is right - practically it doesn’t prevent any mainstream languages working.
Fixing this to make things strict means doing a fair bit of re-arrangement of specs, but which makes no difference at least for languages like Java, C# and (AFAIK) PHP. So I am not sure that the annoyance is worth it right now.
