I think I am mostly with Sebastian here. We know that one of the lessons learnt from the early Template .oet definition is that it can be difficult to separate re-naming of nodes for semantic reasons vs. redifintions simple local synonyms 'displayname' in CDA speak.
I agree, too, that maintaining a specialised node at the end of the chain, allows for further specialisation, without a major version change. A relaxation that might be worth considering is for 'occurrences' . I am not sure whether we would lose much if these did not need specialisation if redefined? They are likely to be the most common sort of redefinition, in Templates, constrained down to 0..0. In comparison name and datatype redefinitions will be comparatively rare. So, I would prefer to keep the original rule for name and datatype redefinitions but relax it for occurences. Ian Dr Ian McNicoll office / fax +44(0)141 560 4657 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com ian at mcmi.co.uk Clinical Analyst Ocean Informatics openEHR Archetype Editorial Group Member BCS Primary Health Care SG Group www.phcsg.org / BCS Health Scotland On 21 May 2010 10:08, Sebastian Garde <sebastian.garde at oceaninformatics.com>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 at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20100521/aaadd2c7/attachment.html>
