...
Component | Impact |
|---|---|
On RM |
|
On existing archetypes |
|
On archetype tooling |
|
On existing RM-1.0.2 based software |
|
On existing RM 1.0.2 data |
|
Discussion
Questions/thoughts from Erik Sundvall:
- The above VALUE_CLUSTER sugestion is an interesting change, and if flexibility is what is sought for, then perhaps the simplification can be taken even further...
- Now the current ITEM+ELEMENT+CLUSTER follows the composite design pattern (see c2 wiki and wikipedia http://en.wikipedia.org/wiki/Composite_pattern). But since there are not many common operations/methods shared by ELEMENTs and CLUSTERs (except the ones already in PATHABLE/LOCATABLE) then perhaps the composite design pattern is not needed/helpful in this part of the openEHR structure. (Also see discussions at CompositeConsideredHarmful and maybe this.)
- If the contents of both ELEMENT and CLUSTER are pushed up to ITEM then we get the same functionality as proposed in VALUE_CLUSTER, but with fewer classes. (ITEM_STRUCTURE will not be needed, see the "Middle and Lower IM"-suggestion further down on this page, but perhaps ITEM_STRUCTURE would be a better name than ITEM for this new super-ITEM with VALUE_CLUSTER capabilities). And one (debatable) way of looking at the ITEM/ITEM_STRUCTURE family of classes is to consider them as being just for structuring and naming nodes internally in a hierarchy and considering the the DATA_VALUE classes to be the real leafs. (Yes, debatable...)
- Perhaps what is mentioned as a "downside" above (not being able to force ELEMENT or CLUSTER) is achievable (if wanted) by archetyping a new super-ITEM to have 0 items (forcing ELEMENT-functionallity) or 1..* items (forcing CLUSTER-functionality)? Also, perhaps "value" can be archetyped as disallowed if you rally want to force value-less CLUSTER behaviour.
...
Candidate B - Remove ITEM_STRUCTURE
...