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 at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
--
Ocean Informatics *Thomas Beale
Chief Technology Officer, Ocean Informatics
<http://www.oceaninformatics.com/>*
Chair Architectural Review Board, /open/EHR Foundation
<http://www.openehr.org/>
Honorary Research Fellow, University College London
<http://www.chime.ucl.ac.uk/>
Chartered IT Professional Fellow, BCS, British Computer Society
<http://www.bcs.org.uk/>
Health IT blog <http://www.wolandscat.net/>
*
*
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20100523/e5dbb591/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ocean_full_small.jpg
Type: image/jpeg
Size: 5828 bytes
Desc: not available
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20100523/e5dbb591/attachment.jpg>
