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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20100521/197ddb3b/attachment.html>
