Rong Chen wrote:
It will be handy to have functions like string_at_path(),
integer_at_path() etc if we do this. The benefit is the client code
doesn't need loop through the types and cast the return value to the
right type. If these seem to be too fine-grained, we could have
primitive_type_at_path(), and domain_type_at_path() to at least get
the root type of these values.
Rong,
I don't disagree with this, but I wouldn't put it in openEHR (or not i
the current release anyway); I think we need to see what emerges out of
the next round of implementation experience.
Ok - unless I get objections I will go with the 2-function solution I
quoted above. I will notify when the formal spec is online with the changes.
- thomas
Dear all,
the CR for this change is at
http://coruscant.chime.ucl.ac.uk:8200/openEHR_Collector/projects/specifications/CR/244
The changed specifications are the Common and EHR IM, in the usual
place. I would be happy to have some volunteers proof read the changes.
I already know I forgot the 'inherit' rows in the table for the
ISM_TRANSITION and INSTRUCTION_DETAILS classes - these are fixed in the
sources and will appear next round.
- thomas
Tom,
Should ACTIVITY be treated the same way as INSTRUCTION_DETAILS? It is
currently inheriting LOCATABLE but is it likely to be archetyped? Actually
it is being archetyped but not the ACTIVITY itself but the ITEM_STRUCTURE
within it so that it can be used in both ACTIVITY and ACTION. Anyway, not
sure why ACTIVITY and INSTRUCTION_DETAILS would be treated differently, one
LOCATABLE, the other PATHABLE. They both have a similar structural pattern
within the RM, is there a different pattern of use?
Heath
Heath Frankel wrote:
Tom,
Should ACTIVITY be treated the same way as INSTRUCTION_DETAILS? It is
currently inheriting LOCATABLE but is it likely to be archetyped? Actually
it is being archetyped but not the ACTIVITY itself but the ITEM_STRUCTURE
within it so that it can be used in both ACTIVITY and ACTION. Anyway, not
sure why ACTIVITY and INSTRUCTION_DETAILS would be treated differently, one
LOCATABLE, the other PATHABLE. They both have a similar structural pattern
within the RM, is there a different pattern of use?
There can be several activities per INSTRUCTION; they are differentiated
on at-code. INSTRUCTION_DETAILS and ISM_TRANSTION are both single
attributes, so archetying doesn't add any meaning.
- thomas