# XML serializer (retry due to too large message)

**Category:** [Technical (archive)](https://discourse.openehr.org/c/technical-archive/156)
**Created:** 2006-11-16 08:31 UTC
**Views:** 1
**Replies:** 26
**URL:** https://discourse.openehr.org/t/xml-serializer-retry-due-to-too-large-message/14601

---

## Post #1 by @Mattias_Forss1

Hi all,

I've just finished implementing an XML serializer. I have followed the XML schema specifications carefully, but I've deviated from some parts, particularly the ontology section. In the terms element (defined as <terms> [ARCHETYPE_TERM](http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/its/XML-schema/documentation/Archetype.xsd.html_h-47810521.html) </terms> [1..*]) found in language_set of term_definitions and constraint_definitions I found the definition of ARCHETYPE_TERM (found here: [http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/its/XML-schema/documentation/Archetype.xsd.html_h-47810521.html](http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/its/XML-schema/documentation/Archetype.xsd.html_h-47810521.html)) to be a little bit strange. You will see that the items element has a hashTableStringString, but I think the entire items element should be replaced with <item> [dictionaryItem](http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/its/XML-schema/documentation/Archetype.xsd.html_h776235118.html) </item> [1..*] or something similar, since there is no need to have a hashTableStringString when there is only one local definition per at/ac-code.

However, I am not sure if I have followed the specifications correctly in some cases - for example when printing the hashTableStringString in the description part. Have a look at my example below and at the specification and provide me with feedback if something is wrong. If there are many errors, maybe the XML specifications should be clarified ;-) I hope to contribute with the XMLSerializer component to the openEHR Java reference implementation.

I also found some other issues in the XML specification, e.g. spelling mistakes etc., which I will provide in another mail. When I went through the specification I started thinking that some things probably could be made a bit more compact. Why not include rm_type_name, node_id/cardinality as attributes in the parent element instead of separate elements. This will make the XML archetypes slightly smaller...

Example of openEHR-EHR-OBSERVATION.height.v1

XML: [http://www.imt.liu.se/~matfo/openEHR-EHR-OBSERVATION.height.v1.xml](http://www.imt.liu.se/~matfo/openEHR-EHR-OBSERVATION.height.v1.xml)
ADL: [http://www.imt.liu.se/~matfo/openEHR-EHR-OBSERVATION.height.v1.adl](http://www.imt.liu.se/~matfo/openEHR-EHR-OBSERVATION.height.v1.adl)

Regards,

Mattias Forss

---

## Post #2 by @Andrew_Patterson

Hi Mattias, I&#39;ve attached my attempt at a serialized adl instance \- perhaps
we can converge on a consensus as to what they should look like\!

Mine is incomplete \- especially around the ontology section \- but I have
done the attributes and children nodes differently, using xsi:type to
indicate the sub\-type\. This is similar to the way Sam did the reference
model serializations I saw, so I thought similar techniques would be
applied here\.

Anyhow, I&#39;m off on another project for a few weeks, but I thought I&#39;d
send you this instance as food for thought\.

Andrew

&lt;at:archetype xmlns:xsi=&quot;http://www.w3.org/2001/XMLSchema-instance&quot;
xmlns:at=&quot;openEHR/v1/Archetype&quot;&gt;
&nbsp;&nbsp;&lt;archetype\_id&gt;openEHR\-EHR\-OBSERVATION\.blood\_pressure\.v1&lt;/archetype\_id&gt;
&nbsp;&nbsp;&lt;concept\_code&gt;at0000&lt;/concept\_code&gt;
&nbsp;&nbsp;&lt;original\_language&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&lt;code\_string&gt;en&lt;/code\_string&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&lt;terminology\_id&gt;iso&lt;/terminology\_id&gt;
&nbsp;&nbsp;&lt;/original\_language&gt;
&nbsp;&nbsp;&lt;description&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&lt;original\_author&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;item&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;key&gt;name&lt;/key&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;value&gt;Sam Heard&lt;/value&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;/item&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;item&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;key&gt;organisation&lt;/key&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;value&gt;Ocean Informatics&lt;/value&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;/item&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;item&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;key&gt;date&lt;/key&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;value&gt;22/03/2006&lt;/value&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;/item&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;item&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;key&gt;email&lt;/key&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;value&gt;sam\.heard@oceaninformatics\.biz&lt;/value&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;/item&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&lt;/original\_author&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&lt;other\_contributors /&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&lt;lifecycle\_state&gt;AuthorDraft&lt;/lifecycle\_state&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&lt;details&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;language&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;code\_string&gt;en&lt;/code\_string&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;terminology\_id&gt;iso639\-1&lt;/terminology\_id&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;/language&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;purpose&gt;To record the systemic blood pressure of a person\. The
measurement records the systolic and the diastolic pressure by some
means suitable for the result to be seen as a surrogate for the
general and systemic blood pressure\.&lt;/purpose&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;keywords&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;item&gt;observations&lt;/item&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;item&gt;blood pressure&lt;/item&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;item&gt;measurement&lt;/item&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;/keywords&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;use&gt;All blood pressure measurements are recorded using this
archetype\. There is a rich state model for use with exercise ECGs and
Tilt Table measurements\.&lt;/use&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;misuse&gt;Not to be used for intravascular pressure\.&lt;/misuse&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&lt;/details&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&lt;resource\_package\_uri&gt;http://www.wow.com&lt;/resource\_package\_uri&gt;
&nbsp;&nbsp;&lt;/description&gt;
&nbsp;&nbsp;&lt;definition&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&lt;rm\_type\_name&gt;OBSERVATION&lt;/rm\_type\_name&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&lt;node\_id&gt;at0000&lt;/node\_id&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&lt;attributes xsi:type=&quot;at:C\_SINGLE\_ATTRIBUTE&quot; minOccurs=&quot;0&quot; maxOccurs=&quot;0&quot;&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;rm\_attribute\_name&gt;guideline\_id&lt;/rm\_attribute\_name&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&lt;/attributes&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&lt;attributes xsi:type=&quot;at:C\_SINGLE\_ATTRIBUTE&quot; minOccurs=&quot;1&quot; maxOccurs=&quot;1&quot;&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;rm\_attribute\_name&gt;data&lt;/rm\_attribute\_name&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;children xsi:type=&quot;at:C\_COMPLEX\_OBJECT&quot;&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;rm\_type\_name&gt;HISTORY&lt;/rm\_type\_name&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;node\_id&gt;at0001&lt;/node\_id&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;attributes xsi:type=&quot;at:C\_MULTIPLE\_ATTRIBUTE&quot; minOccurs=&quot;1&quot;
maxOccurs=&quot;1&quot;&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;rm\_attribute\_name&gt;events&lt;/rm\_attribute\_name&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;children xsi:type=&quot;at:C\_COMPLEX\_OBJECT&quot;&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;rm\_type\_name&gt;EVENT&lt;/rm\_type\_name&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;node\_id&gt;at0006&lt;/node\_id&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;attributes xsi:type=&quot;at:C\_SINGLE\_ATTRIBUTE&quot; minOccurs=&quot;1&quot;
maxOccurs=&quot;1&quot;&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;rm\_attribute\_name&gt;data&lt;/rm\_attribute\_name&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;children xsi:type=&quot;at:C\_COMPLEX\_OBJECT&quot;&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;rm\_type\_name&gt;ITEM\_LIST&lt;/rm\_type\_name&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;node\_id&gt;at0003&lt;/node\_id&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;attributes xsi:type=&quot;at:C\_MULTIPLE\_ATTRIBUTE&quot;
minOccurs=&quot;1&quot; maxOccurs=&quot;1&quot;&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;rm\_attribute\_name&gt;items&lt;/rm\_attribute\_name&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;children xsi:type=&quot;at:C\_COMPLEX\_OBJECT&quot;&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;rm\_type\_name&gt;ELEMENT&lt;/rm\_type\_name&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;occurrences&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;includes\_maximum&gt;true&lt;/includes\_maximum&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;includes\_minimum&gt;true&lt;/includes\_minimum&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;maximum&gt;1&lt;/maximum&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;minimum&gt;0&lt;/minimum&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;/occurrences&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;node\_id&gt;at0004&lt;/node\_id&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;attributes xsi:type=&quot;at:C\_SINGLE\_ATTRIBUTE&quot;
minOccurs=&quot;1&quot; maxOccurs=&quot;1&quot;&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;rm\_attribute\_name&gt;value&lt;/rm\_attribute\_name&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;children xsi:type=&quot;at:C\_QUANTITY&quot;&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;property&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;code\_string&gt;125&lt;/code\_string&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;terminology\_id&gt;openehr&lt;/terminology\_id&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;/property&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;list&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;magnitude&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;maximum&gt;1000&lt;/maximum&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;minimum&gt;0&lt;/minimum&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;/magnitude&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;units&gt;mm\[Hg\]&lt;/units&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;/list&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;/children&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;/attributes&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;/children&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;children xsi:type=&quot;at:C\_COMPLEX\_OBJECT&quot;&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;rm\_type\_name&gt;ELEMENT&lt;/rm\_type\_name&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;occurrences&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;maximum&gt;1&lt;/maximum&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;minimum&gt;0&lt;/minimum&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;/occurrences&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;node\_id&gt;at0005&lt;/node\_id&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;attributes xsi:type=&quot;at:C\_SINGLE\_ATTRIBUTE&quot;
minOccurs=&quot;1&quot; maxOccurs=&quot;1&quot;&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;rm\_attribute\_name&gt;value&lt;/rm\_attribute\_name&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;children xsi:type=&quot;at:C\_QUANTITY&quot;&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;property&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;code\_string&gt;125&lt;/code\_string&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;terminology\_id&gt;openehr&lt;/terminology\_id&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;/property&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;list&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;magnitude&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;maximum&gt;1000&lt;/maximum&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;minimum&gt;0&lt;/minimum&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;/magnitude&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;units&gt;mm\[Hg\]&lt;/units&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;/list&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;/children&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;/attributes&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;/children&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;cardinality&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;is\_ordered&gt;true&lt;/is\_ordered&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;is\_unique&gt;false&lt;/is\_unique&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;interval&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;maximum&gt;0&lt;/maximum&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;minimum&gt;0&lt;/minimum&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;/interval&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;/cardinality&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;/attributes&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;/children&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;/attributes&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;attributes xsi:type=&quot;at:C\_SINGLE\_ATTRIBUTE&quot; minOccurs=&quot;1&quot;
maxOccurs=&quot;1&quot;&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;rm\_attribute\_name&gt;state&lt;/rm\_attribute\_name&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;children xsi:type=&quot;at:C\_COMPLEX\_OBJECT&quot;&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;rm\_type\_name&gt;ITEM\_LIST&lt;/rm\_type\_name&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;node\_id&gt;at0007&lt;/node\_id&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;attributes xsi:type=&quot;at:C\_MULTIPLE\_ATTRIBUTE&quot;
minOccurs=&quot;1&quot; maxOccurs=&quot;1&quot;&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;rm\_attribute\_name&gt;items&lt;/rm\_attribute\_name&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;cardinality&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;is\_ordered&gt;true&lt;/is\_ordered&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;is\_unique&gt;false&lt;/is\_unique&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;interval&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;maximum&gt;0&lt;/maximum&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;minimum&gt;0&lt;/minimum&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;/interval&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;/cardinality&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;/attributes&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;/children&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;/attributes&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;/children&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;cardinality&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;is\_ordered&gt;false&lt;/is\_ordered&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;is\_unique&gt;true&lt;/is\_unique&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;interval&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;maximum&gt;0&lt;/maximum&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;minimum&gt;1&lt;/minimum&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;/interval&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;/cardinality&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;/attributes&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;/children&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&lt;/attributes&gt;
&nbsp;&nbsp;&lt;/definition&gt;
&nbsp;&nbsp;&lt;ontology&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&lt;term\_defintions&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;language&gt;en&lt;/language&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;terms&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;code&gt;at0000&lt;/code&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;items&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;item&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;key&gt;description&lt;/key&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;value&gt;the measurement of system arterial blood pressure
which is deemed to represent the actual systemic blood
pressure&lt;/value&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;/item&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;item&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;key&gt;text&lt;/key&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;value&gt;Blood pressure measurement&lt;/value&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;/item&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;/items&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;/terms&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;terms&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;code&gt;at0001&lt;/code&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;items&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;item&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;key&gt;description&lt;/key&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;value&gt;history structural node&lt;/value&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;/item&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;item&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;key&gt;text&lt;/key&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;value&gt;history&lt;/value&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;/item&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;/items&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;/terms&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;terms&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;code&gt;at0002&lt;/code&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;items&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;item&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;key&gt;description&lt;/key&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;value&gt;baseline event in event history&lt;/value&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;/item&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;item&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;key&gt;text&lt;/key&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;value&gt;baseline reading&lt;/value&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;/item&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;/items&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;/terms&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;terms&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;code&gt;at0003&lt;/code&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;items&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;item&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;key&gt;description&lt;/key&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;value&gt;systemic arterial blood pressure&lt;/value&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;/item&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;item&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;key&gt;text&lt;/key&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;value&gt;blood pressure&lt;/value&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;/item&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;/items&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;/terms&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&lt;/term\_defintions&gt;
&nbsp;&nbsp;&lt;/ontology&gt;
&lt;/at:archetype&gt;

---

## Post #3 by @Mattias_Forss1

Hi Andrew,

I looked at your example and I think it could be a good way to use xsi:type to indicate sub-types where the number of children elements are specified to be only one. This will mean that we don't need to add an extra sub-element, e.g. <description xsi:type="RESOURCE_DESCRIPTION"> (details here: [http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/its/XML-schema/documentation/Archetype.xsd.html_h439624612.html](http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/its/XML-schema/documentation/Archetype.xsd.html_h439624612.html)). However, I don't think the XML schema specification of the AOM explicitly state that xsi:type should be in XML archetypes. I would appreciate if openEHR published some XML archetypes that exemplified the standard way to express them. I don't like the idea of having several ways of representing archetypes in XML so it would be nice if some examples were out to lead the way.

When there are more than one child inside an element, the idea with xsi:type requires us to repeat the container element for each child instead of placing all children inside a single container element, so you have

<attributes xsi:type="at:C_MULTIPLE _ATTRIBUTE" minOccurs="1" maxOccurs="1">
...

<children xsi:type="C_COMPLEX_OBJECT">...</children>
<children xsi:type="C_COMPLEX_OBJECT">...</children>
</attributes>

instead of

<attributes xsi:type="at:C_MULTIPLE _ATTRIBUTE" minOccurs="1" maxOccurs="1">
...
<children>
<C_COMLEX_OBJECT>...</C_COMPLEX_OBJECT>
<C_COMLEX_OBJECT>...</C_COMPLEX_OBJECT>
</children>
</attributes>

The first example is of course more compact, but the element name "children" doesn't make sense, since it doesn't contain all of the attribute's children. The second example will collect all the children in one single container element, but again, I don't know what the specification mean with the occurrences brackets, e.g. what does [0..*] refer to in <children> [C_OBJECT](http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/its/XML-schema/documentation/Archetype.xsd.html_h-1665829344.html) </children> [0..*] ? Does it refer to the <children> element or to the C_OBJECT element? This should be clarified. I have been dealing a lot with ADL and I can say that the second example seems more plausible to me and I see the children element equal to an attribute's "matches {}" in ADL.

Any thoughts about this?

Regards,

Mattias

2006/11/16, Andrew Patterson <[andrewpatto@gmail.com](mailto:andrewpatto@gmail.com)>:

---

## Post #4 by @Heath_Frankel

Hi Mattias,
I would have to agree with Andrew&#39;s approach to serializing the AOM to XML\.
The existence of an XML element representing the AOM type would be
inconsistent with the openEHR RM XML schema and would not work well with
common development framework XML serializers\.  Ocean has also implemented an
XML archetype serializer but I currently don&#39;t have the details on its
output\.  I am sure Sam will make comment when he grounds himself from
travel\.

I think we need to have a more formal approach to gaining consensus on these
kinds of technical artefacts before they are released for community
consumption\.  Having said that, we don&#39;t want this to turn into an endless
process, which when agreeing on an XML representation can easily turn into\.

Regards

Heath

Heath Frankel
Product Development Manager
Ocean Informatics

Ground Floor, 64 Hindmarsh Square
Adelaide, SA, 5000
Australia

ph: \+61 \(0\)8 8223 3075
fax:\+61 \(0\)8 8223 2570
mb: \+61 \(0\)412 030 741
email: heath\.frankel@oceaninformatics\.biz

---

## Post #5 by @Heath_Frankel

Mattias,
You don't seem to follow the AOM when generating your XML instances. For example, the C_MULTIPLE_ATTRIBUTE class has a property of 'members' which is a list of C_OBJECT. This property name should be used in the XML instance so you would get:

<attributes xsi:type="at:C_MULTIPLE _ATTRIBUTE">
<members>

<item xsi:type="C_COMPLEX_OBJECT">...</item>
<item xsi:type="C_COMPLEX_OBJECT">...</item>
</members>
</attributes>

The alternative is to have the following but I suggest that members is not quite right similar to your use of children below.

<attributes xsi:type="at:C_MULTIPLE _ATTRIBUTE">

<members xsi:type="C_COMPLEX_OBJECT">...</members>
<members xsi:type="C_COMPLEX_OBJECT">...</members>
</attributes>

I would also suggest that we should follow the AOM more closely and use an existence element rather than minOccurs and maxOccurs. What you are doing by using the later is mimicking ADL rather than following the AOM. Therefore you would get by following based on the openEHR RM for the Interval type.

<attributes xsi:type="at:C_MULTIPLE _ATTRIBUTE">

<existence>
<lower xsi:type="xs:int">1</lower>
<upper xsi:type="xs:int">1</upper>
...
</existence>
<members>

<item xsi:type="C_COMPLEX_OBJECT">...</item>
<item xsi:type="C_COMPLEX_OBJECT">...</item>
</members>
</attributes>

Regards

Heath

---

## Post #6 by @Mattias_Forss1

Hi Heath,

I know that the C_MULTIPLE_ATTRIBUTE class has a property of 'members' in the AOM (since I know the AOM very much in detail), but it's not in the XML schema specification. I have not followed the AOM, because I thought I was only supposed to look at the schema. Here's the XML schema and XML instance of C_MULTIPLE_ATTRIBUTE with the property 'children' and not 'members' as in the AOM: [http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/its/XML-schema/documentation/Archetype.xsd.html_h783584366.html ](http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/its/XML-schema/documentation/Archetype.xsd.html_h783584366.html). If you could explain a bit more which strategy I should use when generating XML instances I would be very grateful. It seems you suggest I should follow the AOM more closely instead of the XML schema of AOM and its instance representations.

By the way, your second example representation of 'members' is similar to Andrew's example and not mine. I have one container element called 'children', but no xsi:type specified. Where do you get the <item> element name from? I can't find it neither in the XML schema nor the AOM.

Regards,

Mattias

2006/11/17, Heath Frankel <[heath.frankel@frankelinformatics.com](mailto:heath.frankel@frankelinformatics.com)>:

---

## Post #7 by @Andrew_Patterson

> I know that the C\_MULTIPLE\_ATTRIBUTE class has a property of &#39;members&#39; in
> the AOM \(since I know the AOM very much in detail\), but it&#39;s not in the XML
> schema specification\. I have not followed the AOM, because I thought I was
> only supposed to look at the schema\.

The AOM is at fault in this instance \- the AOM has a field defined in
C\_ATTRIBUTE called &#39;children&#39;, and then proceeds to rename this field
to &#39;attributes&#39; and &#39;members&#39; in the two subclasses C\_SINGLE\_ATTRIBUTE
and C\_MULTIPLE\_ATTRIBUTE\. This of course is not really implementable
in any OO style language or XML\.\. the XML schema does the correct
thing and just defines &#39;children&#39; in the base C\_ATTRIBUTE class\.

I have followed the XSD exactly in my serialization\.\. I believe the
intention is that the archetype XSD reflects the AOM model 1:1
\(as much as possible\)\. I see the archetype XSD as a formal
definition of the cotnent of the AOM document\.

Andrew

---

## Post #8 by @Andrew_Patterson

Mattias,

the usage of xsi:type is solely because object hierarchies are being
used in the AOM\. Using xsi:type allows serializers to know the type
they are getting before having to parse it in\.\. however, even without
xsi:type, your serialization would still not be correct for the xsd
given \(i\.e\. let us pretend there is only a C\_ATTRIBUTE, with no
subclasses\)\. Any reference to an element of type C\_ATTRIBUTE
in xml should result in an xml entry named by the &#39;element with
type C\_ATTRIBUTE&#39; i\.e\. &#39;children&#39;\. You never put type names into
the actual xml instances, merely element names\. And for sequences,
this means repeating the xml entry name &#39;children&#39; \(augmented in
this case by an xsi:type to help with the subclasses\)\.

Andrew

---

## Post #9 by @Heath_Frankel

Mattias,
Sorry, I didn't realise this schema was available (I overlooked your reference to it in your original email). OK, so based on this schema the instance is similar to my second example (but using children as the element name rather than members) and your first example, which neither of us like due to the plural nature of the element name for a singular element. I think we need to pass this feedback on to Sam and see if we can ensure that the schema fully reflects the Reference Model including element names that reflect model attribute names such as members and existence.

The usual way a list is represented is a container with multiple items, this is how I came up with this representation of a members element with item child elements. You are right in stating that this is not in the XML schema or AOM, I was looking at this from first principles.

Looking deeper into how the openEHR RM XML schemata represent containment, I find that it has used the pattern suggested in the Archetype XML schema. For example SECTION has element called items that is repeatable. I guess we need to continue with that pattern unless we change the openEHR RM XML schemata as well. The problem with changing this is that the openEHR paths are designed to be compatible with XPath and converting a path such as /content[openEHR-EHR-SECTION-findings.v1]/items[openEHR-EHR-OBSERVATION-laboratory.v1] into XPath and evaluating it will expect to have an XML element called items within an element called content.

Therefore I suggest that based on the current XML schema your instance should look like your first example:

<attributes xsi:type="at:C_MULTIPLE _ATTRIBUTE" minOccurs="1" maxOccurs="1">
...

<children xsi:type="C_COMPLEX_OBJECT">...</children>
<children xsi:type="C_COMPLEX_OBJECT">...</children>
</attributes>

However, I would advocate that we should submit a change request to change the schema to use the element name of members rather than children. There are probably other AOM alignments required.

Additionally I would like to see the use of an existence element of type INTEGER_INTERVAL (i.e. INTERVAL<integer>) rather than minOccurs & maxOccurs. Thoughts?

Heath

---

## Post #10 by @Heath_Frankel

> The AOM is at fault in this instance \- the AOM has a field
> defined in C\_ATTRIBUTE called &#39;children&#39;, and then proceeds
> to rename this field to &#39;attributes&#39; and &#39;members&#39; in the two
> subclasses C\_SINGLE\_ATTRIBUTE and C\_MULTIPLE\_ATTRIBUTE\. This
> of course is not really implementable in any OO style
> language or XML\.\. the XML schema does the correct thing and
> just defines &#39;children&#39; in the base C\_ATTRIBUTE class\.
>
> I have followed the XSD exactly in my serialization\.\. I
> believe the intention is that the archetype XSD reflects the
> AOM model 1:1 \(as much as possible\)\. I see the archetype XSD
> as a formal definition of the cotnent of the AOM document\.
>

Oh, so that&#39;s why I got confused why members was implemented as a method
rather than an attribute, I didn&#39;t make the correlation between members and
children \(perhaps I should have read the words rather than just the picture
:&gt;\)\.

In that case, the XML schema does not require a change request for this
issue\.  I would still like to explore the use of an existence element rather
than minOccurs and maxOccurs attributes\.  I don&#39;t see why existence and
occurrences in C\_OBJECT are treated differently\.  And then I think the
interval\_of\_integer type should use elements lower and upper as per the
Interval assumed type specified in the openEHR Support package\.

Heath

---

## Post #11 by @Mattias_Forss1

2006/11/17, Andrew Patterson <[andrewpatto@gmail.com](mailto:andrewpatto@gmail.com)>:

> > I know that the C_MULTIPLE_ATTRIBUTE class has a property of 'members' in
> > the AOM (since I know the AOM very much in detail), but it's not in the XML
> > schema specification. I have not followed the AOM, because I thought I was
> > only supposed to look at the schema.
>
> The AOM is at fault in this instance - the AOM has a field defined in
> C_ATTRIBUTE called 'children', and then proceeds to rename this field
> to 'attributes' and 'members' in the two subclasses C_SINGLE_ATTRIBUTE
> and C_MULTIPLE_ATTRIBUTE. This of course is not really implementable
> in any OO style language or XML.. the XML schema does the correct
> thing and just defines 'children' in the base C_ATTRIBUTE class.

No, it proceeds to rename this field to 'alternatives' (not attributes) and 'members'.

I agree, that it's not OO style, but why isn't it implementable in XML? XML isn't OO, it's just a way of storing structured information, and the guys building the XML parsers to create the AOM objects again can probably deal with that. But since the AOM is OO I guess it wouldn't be a bad idea if the contents of the XML instances were in OO style.

Mattias

---

## Post #12 by @Mattias_Forss1

Well, I'm no expert on XSD since I never cared about learning it... but if I go back to your example, why didn't you use xsi:type in some places, for example:

<description>
<original_author>
<item> ...

Is you used it here it would be:

<description xsi:type="RESOURCE_DESCRIPTION">
<original_author xsi:type="hashTableStringString">
<item xsi:type="dictionaryItem"> ...

Regards,

Mattias

2006/11/17, Andrew Patterson <[andrewpatto@gmail.com](mailto:andrewpatto@gmail.com)>:

---

## Post #13 by @Andrew_Patterson

> go back to your example, why didn&#39;t you use xsi:type in some places, for
> example:
>
> &lt;description&gt;
> &nbsp;&nbsp;&nbsp;&nbsp;&lt;original\_author&gt;
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;item&gt; \.\.\.
>
> Is you used it here it would be:
>
> &lt;description xsi:type=&quot;RESOURCE\_DESCRIPTION&quot;&gt;
> &nbsp;&nbsp;&nbsp;&nbsp;&lt;original\_author xsi:type=&quot;hashTableStringString&quot;&gt;
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;item xsi:type=&quot;dictionaryItem&quot;&gt; \.\.\.

because there are no doubts about the actual type of
&#39;description&#39; \(i\.e\. it has no subclasses\), when the
serialiazer gets to the &#39;description&#39; node\. it knows
what to expect\. If we had a RESOURCE\_DESCRIPTION\_EXTENDED
complexType that was based on RESOURCE\_DESCRIPTION,
then we would need to use xsi:type\.

Andrew

---

## Post #14 by @Mattias_Forss1

Heath, I must say that I have come to agree with you (and Andrew concerning the repeating of 'children' for multiple children) - but lets hear what Sam has to say about the changes you propose.

Mattias

2006/11/17, Heath Frankel <[heath.frankel@frankelinformatics.com](mailto:heath.frankel@frankelinformatics.com)>:

---

## Post #15 by @system

Mattias Forss schreef:
> Well, I&#39;m no expert on XSD since I never cared about learning it\.\.\.
> but if I go back to your example, why didn&#39;t you use xsi:type in some
> places, for example:

I don&#39;t know if you ever saw this site, I did, it was helpful

Bert

---

## Post #16 by @Andrew_Patterson

> I agree, that it&#39;s not OO style, but why isn&#39;t it implementable in XML? XML
> isn&#39;t OO, it&#39;s just a way of storing structured information, and the guys
> building the XML parsers to create the AOM objects again can probably deal
> with that\.

The use of complexType with extensions in XSD follows the OO
model\. So if it has a field called &#39;children&#39; in C\_ATTRIBUTE, that
field is going to be in all in extensions \- called &#39;children&#39;\.\. if those
sub classes also define a similar field, then they will have two
fields\. I just presumed that the AOM had a textual mistake
\(whilst the &#39;alternatives&#39; and &#39;members&#39; are more correct descriptions
of the attribute, they technically are still &#39;children&#39; so I don&#39;t see
a problem with them having that inherited field and using it to
store alternatives and members respectively\)\.

Andrew

---

## Post #17 by @system

Bert Verhees schreef:

> ```
> Mattias Forss schreef:
>
> ```
>
> > ```
> > Well, I'm no expert on XSD since I never cared about learning it...
> > but if I go back to your example, why didn't you use xsi:type in some
> > places, for example:
> >
> > ```
>
> ```
> I don't know if you ever saw this site, I did, it was helpful
>
> ```

[http://www.w3schools.com/schema/default.asp](http://www.w3schools.com/schema/default.asp)

(forgot ;-)

---

## Post #18 by @Mattias_Forss1

2006/11/17, Heath Frankel <[heath.frankel@frankelinformatics.com](mailto:heath.frankel@frankelinformatics.com)>:

> > The AOM is at fault in this instance - the AOM has a field
> > defined in C_ATTRIBUTE called 'children', and then proceeds
> > to rename this field to 'attributes' and 'members' in the two
> > subclasses C_SINGLE_ATTRIBUTE and C_MULTIPLE_ATTRIBUTE. This
> > of course is not really implementable in any OO style
> > language or XML.. the XML schema does the correct thing and
> > just defines 'children' in the base C_ATTRIBUTE class.
> >
> > I have followed the XSD exactly in my serialization.. I
> > believe the intention is that the archetype XSD reflects the
> > AOM model 1:1 (as much as possible). I see the archetype XSD
> > as a formal definition of the cotnent of the AOM document.
> >
> Oh, so that's why I got confused why members was implemented as a method
> rather than an attribute, I didn't make the correlation between members and
> children (perhaps I should have read the words rather than just the picture
> :>).

Oops, I also missed that it was a function :-)

Maybe the specs could distinct attributes, functions, etc with different coloring.

> In that case, the XML schema does not require a change request for this
> issue. I would still like to explore the use of an existence element rather
> than minOccurs and maxOccurs attributes. I don't see why existence and
> occurrences in C_OBJECT are treated differently. And then I think the
> interval_of_integer type should use elements lower and upper as per the
> Interval assumed type specified in the openEHR Support package.

Agree

Mattias

---

## Post #19 by @Mattias_Forss1

All right then, so now I know how I should proceed. Thank you very much for your help. It was a lot faster to understand the schema by your input rather than starting to read some XSD documentation.

Regards,

Mattias

2006/11/17, Andrew Patterson <[andrewpatto@gmail.com](mailto:andrewpatto@gmail.com)>:

---

## Post #20 by @Heath_Frankel

Actually, the AOM represents alternatives and members as methods not as
attributes\.  These methods obviously return the children attribute\.

Heath

---

## Post #21 by @Mattias_Forss1

2006/11/17, Bert Verhees <[bert.verhees@rosa.nl](mailto:bert.verhees@rosa.nl)>:

> Bert Verhees schreef:
>
> > ```
> > Mattias Forss schreef:
> >
> > ```
> >
> > > ```
> > > Well, I'm no expert on XSD since I never cared about learning it...
> > > but if I go back to your example, why didn't you use xsi:type in some
> > > places, for example:
> > >
> > > ```
> >
> > ```
> > I don't know if you ever saw this site, I did, it was helpful
> >
> > ```
>
> [http://www.w3schools.com/schema/default.asp](http://www.w3schools.com/schema/default.asp)
>
> (forgot ;-)

Yes, the tutorials by W3 schools are nice, but most often not as detailed as one might wish.

//Mattias

---

## Post #22 by @Mattias_Forss1

Andrew,

In your example, you have the other_contributors element even when it has no children, but the schema specification says that it's optional, i.e. <other_contributors> [list_of_string](http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/its/XML-schema/documentation/Archetype.xsd.html_h-2045140803.html) </other_contributors> [0..1]. Shouldn't you discard that element when the list of contributors is empty?

/Mattias

2006/11/16, Andrew Patterson < [andrewpatto@gmail.com](mailto:andrewpatto@gmail.com)>:

---

## Post #23 by @Andrew_Patterson

> &lt;other\_contributors&gt; list\_of\_string &lt;/other\_contributors&gt; \[0\.\.1\]\. Shouldn&#39;t
> you discard that element when the list of contributors is empty?

That&#39;s a mistake by me\.\. I think I was experimenting to see whether
empty lists were serialized out as the empty element \(as in this
case\) or whether it would discard them entirely\. But you are right that
it shouldn&#39;t there at all\.

Andrew

---

## Post #24 by @Sam

Hello everyone

Good work - and good to see others get into this space. It would be good if we could agree the AOM. Infact I could load Andrew's archetype which was good! Just had one bug with C_QUANTITY - I need the rm_type_name for my code to run rather than just using the type. Looking at the SCHEMA this is a required attribute on all C_OBJECTs so it should not parse.

The Ontology is so huge I have wondered about having the Text and Description as attributes - it would save a lot of space and I do not think it would complicate things at all.

What do others think?

Cheers, Sam

Andrew Patterson wrote:

---

## Post #25 by @Mattias_Forss1

2006/11/21, Sam Heard <[sam.heard@oceaninformatics.biz](mailto:sam.heard@oceaninformatics.biz)>:

> The Ontology is so huge I have wondered about having the Text and Description as attributes - it would save a lot of space and I do not think it would complicate things at all.
>
> What do others think?

Sounds like a good idea as long as the two parts (text, description) of the description items will remain. If more parts are added though, it is not a flexible solution.

Mattias

---

## Post #26 by @Sam

Hi
We can add more attributes safely.....which I think is all that could be done without changing the model in a major manner, Sam

Mattias Forss wrote:

---

## Post #27 by @Heath_Frankel

Sam,
It is only safe if the attributes are primitive types. However I think it would be a good saving considering the current attributes.

Heath

---


**Canonical:** https://discourse.openehr.org/t/xml-serializer-retry-due-to-too-large-message/14601
**Original content:** https://discourse.openehr.org/t/xml-serializer-retry-due-to-too-large-message/14601