Sebastian,
I messed around with the compiler to allow this change, and came to the
conclusion that it is probably not such a good idea, for some of the
reasons you indicate below. I did think about the later redefinition
of a single child into multiples, and this particularly would be very
annoying to handle.
So the question is whether to go back to the previous rule, which was:
- any change to RM type or occurrences means node_id must
be specialised; in addition node_id may be specialised on its own for
semantic reasons.
Do we relax this to allowing change to occurrences, as Ian suggested
(and this was the original reason I considered this change) or do we
stay 100% strict. If we stay strict, it means that if you create a
specialised archetype and only change (i.e. reduce) the occurrences of
a node, you (the tool) are forced to specialise the at-code. Now, a
purist might argue that you have indeed changed the meaning in some
way. For example if you reduce the number of allowed events from 0..*
to 1, then you have subtly redefined the event meaning from 'any event'
to 'single measurement event' or so. Maybe the tools should just
redefine the at-code automatically and create a meaning like 'xxxx
(redefined occurrences)'. But then this has to be managed in all the
translations as well. It would not be a major problem, and probably we
should just see it as a normal part of redefinition of archetypes. Note
that in ADL 1.5, this reasoning applies to templates as well.
I will experiment with the setting where occurrences can change without
forcing at-code change for the moment.
all thoughts welcome.
- thomas
On 21/05/2010 10:08, Sebastian Garde wrote:
Hi Thomas,
A few concerns that come to my mind - I am not so sure that
removing/changing this rule is a good thing:
- It puts an additional burden on tools to support both ways of
creating a specialised node wither with or without specialised at code.
- It puts an additional burden on users that need to decide
whether
a specialised node should be created because the semantics have changed
- I don't think this decision is always that clear cut.
- What if the non-semantically specialised node is LATER
redefined
into multiple children? Then a new version of the archetype is needed
instead of just a revison?
- With the stricter rule it a lot easier to recognize what has
changed from parent to child archetype (this may not apply to 1.5
source ADL, but to the flat files anyway)
- In general, I believe that these validity rules should be
simple
and straightforward, rather than complex "if this and that and then
this, you need a specialised code"-statements.
Sebastian
Thomas Beale wrote:
I am in the middle of ADL/AOM 1.5 testing. There is a validity rule I
defined in the current draft specficatich reads as fllows:
VSONIR: specialised archetype object node redefinition: if it exists,
the node identifier of an object node in a specialised archetype must
be redefined into its specialised form if either reference model type
or occurrences of the immediate object constraint is redefined.
Translation: change of occurrences or change of RM type (e.g. redefine
into descendant type) requires a specialised at-code, e.g. at0002
--> at0002.1 or similar.
In processing real archetypes and creating new templates, I am inclined
to remove this rule, and say that the at-code only has to be
specialised if the archetype author wishes to do so for semantic
reasons OR if the parent node is redefined into multiple
children (e.g. a node at0013 meaning 'panel item' gets specialised into
at0013.1 (serum sodium), at0013.2, (serum potassium), at0013.3, etc).
I will experiment with removing this rule for the moment, and see if
anything bad happens, but as far as I can see, nothing will. If we
throw it away, it means that at-code specialisation really is only for
semantic reasons, which would be nice and clean.
I am interested in any opinions on this.
By way of news: I am very close to a working implementation of AOM/ADL
1.5, and will release a new version of the ADL Workbench soon/
- thomas beale
_______________________________________________
openEHR-technical mailing list
openEHR-technical@openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
|
