On 1/8/07, Thomas Beale <Thomas.Beale at oceaninformatics.biz> wrote:
>
>
> >
> > 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]? 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;-)I also noticed the lacking of support for occurrencies in some of the C_OBJECT subclasses including ARCHETYPE_INTERNAL_REF. It's no problem to add that. I just need an example archetype for this. Yes, we _really_ need a common test archetype coverage for all the parsers. :-) /Rong >> 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 > http://www.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/20070108/5dc5e2f8/attachment.html> -------------- next part -------------- _______________________________________________ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
