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
|