Probably this is another case where the existence attribute creates ambiguity.
As stated in http://www.openehr.org/wiki/display/dev/Existence+of+Attributes+%28AOM,+ADL+and+XML%29 http://www.openehr.org/wiki/display/dev/Existence+of+Attributes+%28AOM,+ADL+and+XML%29 , Java reference adl parser and serializer consider the absence of existence attribute as [1..1] as default. I imagine we can consider this as a temporary anomaly and assuming existence attribute of "protocol" and "state" as [0..1]. leo Alessandro Torrisi-3 wrote: > > Leo, > > it is an interseting question. > > in general it is 0..1 we agree on that > if it is defined in the archetype i think it is mandatory, so 1..1 > > however the items inside the ITEM_STRUCTURE (suppose ITEM_TREE) can be set > to 0..1 > > so.. it is requierd, but not the content.. > > Alessandro > > > > > On 16 July 2010 14:09, Leonardo Moretti <lmoretti at noemalife.com> wrote: > >> >> Thanks Alessandro, >> yes you are right, generally protocol is optional in RM, but I'm >> wondering >> if it becomes mandatory when defined in the archetype. >> ADL doesn't explicit the occurrences of protocol (I imagine the default >> is >> 0..1), but in XML representation of the archetype I find >> ... >> <attributes xsi:type="C_SINGLE_ATTRIBUTE"> >> <existence> >> <lower_unbounded>false</lower_unbounded> >> <upper_unbounded>false</upper_unbounded> >> <lower>1</lower> >> <upper>1</upper> >> </existence> >> <rm_attribute_name>protocol</rm_attribute_name> >> <children xsi:type="C_COMPLEX_OBJECT"> >> <rm_type_name>ITEM_TREE</rm_type_name> >> <occurrences> >> <upper_included>true</upper_included> >> <lower_included>true</lower_included> >> <upper_unbounded>false</upper_unbounded> >> <lower_unbounded>false</lower_unbounded> >> <upper>1</upper> >> <lower>1</lower> >> </occurrences> >> <node_id>at0011</node_id> >> ... >> >> where lower occurences number is 1 and not 0! Maybe is the XML >> serialization >> wrong!? >> >> leo >> >> >> Alessandro Torrisi-3 wrote: >> > >> > Leo, >> > >> > perhaps you can look to this : >> > >> > >> http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/rm/ehr_im.pdf >> > >> > then section 8.3.3. CARE_ENTRY Class >> > >> > over there you can see that protocol is 0..1 So never be mandatory >> > >> > Alessandro >> > >> > >> > On 16 July 2010 11:47, Leonardo Moretti <lmoretti at noemalife.com> wrote: >> > >> >> >> >> Hi Alessandro, >> >> items cardinality matches {0..*; unordered} is referred to "items" >> >> elements, >> >> not to "protocol" element >> >> >> >> This means we can have something like this: >> >> <observation> >> >> <data> >> >> ... >> >> </data> >> >> <protocol archetype_node_id="at0011" xsi:type="ITEM_TREE"> >> >> <name> >> >> <value>*List(en)</value> >> >> </name> >> >> </protocol> >> >> <observation> >> >> >> >> Is the section >> >> <protocol archetype_node_id="at0011" xsi:type="ITEM_TREE"> >> >> <name> >> >> <value>*List(en)</value> >> >> </name> >> >> </protocol> >> >> mandatory, even if it doesn't have any items? >> >> Looking at the archetype defintion, so it seems! >> >> >> >> leo >> >> >> >> >> >> Alessandro Torrisi-3 wrote: >> >> > >> >> > Leo, >> >> > >> >> > as far as i can see the protocol section is not mandatory : >> >> > >> >> > protocol matches { >> >> > ITEM_TREE[at0011] matches { -- lijst structuur >> >> > items cardinality matches {0..*; unordered} matches { >> >> > >> >> > as you can see 0..* (means zero times until unbounded times), so not >> >> > mandatory >> >> > >> >> > Alessandro >> >> > >> >> > >> >> > On 15 July 2010 17:57, Moretti Leonardo <lmoretti at noemalife.com> >> wrote: >> >> > >> >> >> Hi all, >> >> >> I have a doubt in interpretating the archetype definition when >> there >> >> are >> >> >> "state" or "protocol" structure. For example, looking at "Blood >> >> >> Pressure" in http://openehr.org/knowledge/, I'm wondering if >> >> "protocol" >> >> >> structure is mandatory, as it seems looking at the archetype. If I >> >> don't >> >> >> know any details about the protocol, do I have to insert an empty >> tag >> >> >> <protocol> however? >> >> >> >> >> >> Best regards >> >> >> leo >> >> >> >> >> >> _______________________________________________ >> >> >> openEHR-technical mailing list >> >> >> openEHR-technical at openehr.org >> >> >> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >> >> >> >> >> > >> >> > >> >> > >> >> > -- >> >> > Alessandro Torrisi >> >> > >> >> > _______________________________________________ >> >> > openEHR-technical mailing list >> >> > openEHR-technical at openehr.org >> >> > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >> >> > >> >> > >> >> >> >> -- >> >> View this message in context: >> >> >> http://old.nabble.com/%22state%22-and--%22protocol%22-structures-are-mandatory%2C-when-defined--tp29174701p29181878.html >> >> Sent from the openehr-technical mailing list archive at Nabble.com. >> >> >> >> _______________________________________________ >> >> openEHR-technical mailing list >> >> openEHR-technical at openehr.org >> >> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >> >> >> > >> > >> > >> > -- >> > Alessandro Torrisi >> > >> > _______________________________________________ >> > openEHR-technical mailing list >> > openEHR-technical at openehr.org >> > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >> > >> > >> >> -- >> View this message in context: >> http://old.nabble.com/%22state%22-and--%22protocol%22-structures-are-mandatory%2C-when-defined--tp29174701p29182934.html >> Sent from the openehr-technical mailing list archive at Nabble.com. >> >> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical at openehr.org >> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >> > > > > -- > Alessandro Torrisi > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > -- View this message in context: http://old.nabble.com/%22state%22-and--%22protocol%22-structures-are-mandatory%2C-when-defined--tp29174701p29267422.html Sent from the openehr-technical mailing list archive at Nabble.com.
