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:openehr-technical-boun...@lists.openehr.org]
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>
