On 01/07/2013 02:40 AM, Thomas Beale wrote:
> On 06/01/2013 20:29, Bert Verhees wrote:
>> On 01/06/2013 08:44 PM, Thomas Beale wrote:
>>>
>>> Hi Bert,
>>>
>>> existence is a property of CAttribute (multiple or single). It
>>> indicates if the attribute value (i.e. some object) must exists or
>>> can be null.
>>>
>>
>> How about this:
>>
>> Since its function in CSingleAttribute is also done by
>> CObject-attribute occurences, it could be removed from the
>> CSingleAttribute. This would make tools that check this superfluous.
>
> Hi Bert,
>
> it can't really, because you can have CAttributes that have no CObject
> children. Setting the existence to {1} for example on such an
> attribute says that there have to be values, but says nothing further
> about them.
>
> On the other hand, if there are child CObjects, these CObjects could
> each have occurrences set to {0..1} (e.g. if they are alternatives).
>
> so it's not quite as simple as it seems. There probably is a
> simplification available in the future, but my suggestion for now,
> assuming you are using the Java library and existing openEHR
> archetypes, is to stick with the way the library works at the moment -
> I assume it does sensible things...
I think, Thomas, the logic is as follows, the CSingleAttribute can, as
in the specs, have one or more then one children (CObjects).
Only one can be chosen, the others are alternatives.
The CSingleAttribute can have existence 0..1 (OPTIONAL), 1..1 (REQUIRED)
and 0..0 (NOTALLOWED).
The last one I don't understand, why having an attribute as it is
defined to stay null.
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
-----
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 am also looking further than the existing Java-libraries, but that I
will soon announce more about this.
Thanks, for helping me think about this matter.
Best regards
Bert
