...
- ITEM_STRUCTURE now inherits from CLUSTER.
- all static declarations in the remainder of the RM for ITEM_STRUCTURE changed to CLUSTER. In theory they should stay ITEM_STRUCTURE, but the problem is that with no static declarations anywhere for CLUSTER or ITEM, CLUSTER archetypes have no place to go, and the CLUSTER type is not detected by my current 'type closure' detecting algorithm. This should probably be changed.
- the types ITEM_TREE, ITEM_SINGLE, ITEM_TABLE, ITEM_LIST could be kept as programming types for manipulating the specific kinds of data structure.
Diagram
Impact Analysis
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 |
|
...
A new VALUE_CLUSTER, inheriting from ELEMENT and CLUSTER provides the semantics of both: a node which can itself have a value (like an ELEMENT), but may still hvae substructure. By inheriting from both CLUSTER and ELEMENT, it means that where either of these two are currently specified in the RM or archetypes, VALUE_CLUSTER could be substituted at runtime.The downside of this model is that there is no way to force a node to be just an ELEMENT or CLUSTER, since the new type is always substitutable.
Diagram
Impact Analysis
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 |
|
...
- 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
Proposal - Pablo Pazos
Status
...
- Removed ITEM_STRUCTURE and children.
- Added attribute structure_type:CODE_PRHASE to CLUSTER (as in 13606 model)
- Added method is_root() to ITEM
- ITEM inherits from DATA_STRUCTURE
- Added backguards relationship "parent" from ITEM to CLUSTER
Diagram
I have the source of this diagram if anyone wants it, it's a .dia file (http://live.gnome.org/Dia)
...