Hi Bert
I have been a little irritating about this in the past. The single attribute could be determined by occurrences but I am not sure of the downstream implications at this stage. My interest has been in existence as a constraint. Clearly everything is logically optional at any level if existence is to have any relevance. Existence as a constraint is therefore binary - something is mandatory or prohibited. I have proposed in XML that we have existence as a binary statement 0 or 1. The expression of existence is clearly a tertiary state - optional as well as mandatory or prohibited - it is only as a constraint that it is binary. Cheers, Sam From: openEHR-technical [mailto:[email protected]] On Behalf Of Thomas Beale Sent: Monday, 7 January 2013 9:57 PM To: openehr-technical at lists.openehr.org Subject: Re: csingleattribute and existence 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 <mailto:openEHR-technical at lists.openehr.org> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.or g -- Thomas Beale Chief Technology Officer, Ocean Informatics <http://www.oceaninformatics.com/> Chair Architectural Review Board, <http://www.openehr.org/> openEHR Foundation 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/20130108/0cbc2e9a/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 5828 bytes Desc: not available URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130108/0cbc2e9a/attachment-0001.jpg>
