Bert, one very useful thing you can do is to identify guidelines for use of the current specification. E.g. statements of the form
if existence is set on a single-valued attribute, and there is only one child object, no occurrences should be set, since they can always be inferred from the owning attribute's existence. and so on. These kind of statements I can add to the ADL 1.5 spec (which we should treat as the usable spec these days). thanks - thomas On 07/01/2013 11:21, Bert Verhees wrote: > >>> 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 > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > -- 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/pipermail/openehr-technical_lists.openehr.org/attachments/20130107/019d3149/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/pipermail/openehr-technical_lists.openehr.org/attachments/20130107/019d3149/attachment.jpg>
