>> But besides that, suppose you have a CSingleAttribute with REQUIRED >> set with more CObjects as alternatives in it. >> All occurrences for the CObjects need then to be set to 0..1, every >> other setting is erroneous. >> Occurrences 0..0 is useless, why define a CObject if it may never occur. >> Occurrences 1..1 is useless, why define alternative CObjects if the >> one chosen is defined. >> >> Maybe the occurrences of CObjects should not be looked at when child >> of a CSingleAttribute > > occurrences can be 1..1 if it is the only possibility.
My statement was that it is useless, it can be possible but has no meaning. Skipping the alternatives is more clear. And if there are no alternatives, setting the CSingleAttribute.existence to REQUIRED does the same. > > occurrences can be 0..1 on two alternatives, with an additional rule > that says that either A or B must be there (thus satisfying the 1..1 > in the attribute itself) That is the only meaningful occurrence possible in the CObject. So if there is only one meaningful, what is the point of making it configurable? > >> ----- >> It is that I am looking further in the world then existing archetypes. >> We had the discussion about the tried enforcing top-down-structure of >> archetypes and the consequences of this policy a few weeks ago. > > I'm not sure how this relates to the technical issue we are discussing > here...? It is because you advised me to use the existing OpenEHR archetypes and Java-implementation. I indicated why I don't do that exclusively. > >> >> I am also looking further than the existing Java-libraries, but that >> I will soon announce more about this. > > I am not claiming that the current specification approach is perfect. > But the experience I know about elsewhere leads me to think it is > pretty workable; we don't seem to have any problems in most tools or > libraries on this issue. > > If there are aspects you are thinking about in some other kind of > archetype, please share it, that would help. No it is not perfect, and yes it is workable. My suggestions were partly that I was not sure to understand the construct well, and partly to discuss improvements. When I have other issues, I will gladly discuss them. Bert
