Hi all, we have a doubt regarding the possibility of overriding occurrences of referenced node. The main concern has to do with the fact that a occurrence constraint is "part" of the semantics of the node being constrained. If it is true, when overriding the occurrences of referenced nodes, do we change the meaning of the original node and therefore the description (and even terminology binding) might become erroneous?.
best regards Mattias Forss escribi: > > > 2007/1/8, Thomas Beale <Thomas.Beale at oceaninformatics.biz > <mailto:Thomas.Beale at oceaninformatics.biz>>: > > > > > > Koray Atalag wrote: > >> QUESTION-1: What is the correct approach for above problem? > >> > as Sam has said your understanding is correct and the archetype is > in error. > >> QUESTION-2: Assume in some other place in the archetype you > reference > >> the ELEMENT node with occurences {0..8} by use_node. And in this > >> particular place you do not want to have up to 8 instances and > but also > >> you want it to be mandatory (i.e. 1..) or even want {3..5}. > What is the > >> solution? (other than writing the whole thing once again) > >> > the current semantics are that the occurrences of the referenced node > are what takes effect. However, I agree that a preferable approach > would > be if the occurrences could be overridden at the origin point of the > use_node reference. This would not be incompatible with the current > semantics, and would probably be a useful change. What do others > think? > [Particularly the Archetype tool authors]? > > > Hi Thomas, > > I think it would be a good idea to let the users of the archetype > editors override occurrences of referenced nodes. > > Regards, > > Mattias > > Note that in the AOM, an > ARCHETYPE_INTERNAL_REF inherits occurrences from C_OBJECT, so in > theory > our archetype parsers should handle them, but I have just looked at > mine, and it doesn't...Rong, how about the Java parser? (So much for > having complete test archetype coverage;-) > >> QUESTION-3: Related with second question, I also need to > disallow usage > >> of some values when referencing by use_node entries. This I > believe is > >> not an uncommon requirement in clinical medicine.For me I have an > >> element with a long list of values of sites of an organ > (Esophagus, > >> stomach, colon and so on) and in many places of an observation > these > >> sites repeat without change so I can reference original. But in > some > >> cases selection of certain site(s) is not logical and should > better be > >> restricted or selection of only one site makes sense. What is > the solution? > >> > I actually think there are various solutions here... > * the most obvious would be that at the point of reference, you > create a > CLUSTER node, and then individually reference the subset of paths of > items from the target CLUSTER that you want, but not others. > * another one would be to make a number of ITEM_TREE or ITEM_LIST > archetype of the relevant piece of content as separate archetypes, > and > use slots to include particular subsets. > * a third possibility is to use invariants to prevent certain > paths from > existing that would otherwise be allowed by the main part of the > definition of the archetype. > > - thomas beale > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org <mailto:openEHR-technical at openehr.org> > http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > >------------------------------------------------------------------------ > >_______________________________________________ >openEHR-technical mailing list >openEHR-technical at openehr.org >http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > -- Jose A. Maldonado. Ph. D. Bioengineering, Electronic and Telemedicine Group Escuela Universitaria de Informatica Technical University of Valencia Camino Vera s/n 46022 VALENCIA (Spain) Tel. + 34 96 387 70 07 ext: 75277 e-mail: jamaldo at upvnet.upv.es http://bet.upv.es -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20070108/4a60e587/attachment.html> -------------- next part -------------- _______________________________________________ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
