# bugs in domain types in XMLserializer

**URL:** <https://discourse.openehr.org/t/bugs-in-domain-types-in-xmlserializer/15126>\
**Category:** Reference Implementation: Java (archive)\
**Created:** [9 January 2012 08:23 UTC](https://discourse.openehr.org/t/bugs-in-domain-types-in-xmlserializer/15126 "2012-01-09T08:23:31Z")\
**Posts on this page:** 11\
**Page:** 1

<div class="post-metadata">

**Author:** ![yampeku](https://discourse.openehr.org/user_avatar/discourse.openehr.org/yampeku/32/25_2.png) [@yampeku](https://discourse.openehr.org/u/yampeku)\
**Post date:** [9 January 2012 08:23 UTC](https://discourse.openehr.org/t/bugs-in-domain-types-in-xmlserializer/15126/1 "2012-01-09T08:23:31Z")

</div>

Hello everyone 🙂

This one is related to my post on the the technical list. I have found  
some missing things on the XMLserializer (I would make the changes  
myself, but I have yet to connect to the SVN)

-regarding domain types:  
-missing assumed\_values in both schema and the serializer  
-code\_phrase: code\_list is really called code\_string on the schema

I have also found some places (printCDate, printCDateTime, etc.) where  
the java implementation is more powerful than both the schema and  
serializer (for defining things like lists of dates). In fact, those  
things in ADL work just fine (you can define a list of dates) but the  
XML generation can't generate it. Simply putting something like this

if(cdatetime.getList() != null) {  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;printList(cdatetime.getList(), out);  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}

on every one of the printCDateXXX would make it work (but again, this  
is not on the schema)

Also, does someone know why 'expression' from the assertions is  
obligatory on the AOM (which reflects on archetype slots) as this is  
not the case on ADL slots definition?

Regards

---

<div class="post-metadata">

**Author:** ![system](https://discourse.openehr.org/uploads/default/original/2X/f/f0a1dedb20c42747bddcafd6c7df9db5f34f003c.svg) [@system](https://discourse.openehr.org/u/system)\
**Post date:** [11 January 2012 09:59 UTC](https://discourse.openehr.org/t/bugs-in-domain-types-in-xmlserializer/15126/2 "2012-01-11T09:59:45Z")

</div>

Hi Diego,

Thanks for the report. The XMLSerializer (of ADL) is obviously not up-to-date.

The original work was done and donated by a master thesis student at  
Linköping University years ago. Over time, there have been small fixes  
on the component by various developers.

The main issue with this ADL XMLserializer, I believe I have said it  
before on the list, is that it has all the Archetype XML Schema  
embedded in the source code. This makes it very vulnerable to changes  
in the specs. A much better approach is to do a binding (mapping)  
directly between AOM objects and generated object model from Archetype  
XML schema, by JAXB for example. The RM XML-binding component is built  
with this approach, and is therefore much smaller, more maintainable.

If someone on this list would like to build a schema-driving AOM/XML  
binding component for archetypes, I would appreciate that =)

/Rong

---

<div class="post-metadata">

**Author:** ![yampeku](https://discourse.openehr.org/user_avatar/discourse.openehr.org/yampeku/32/25_2.png) [@yampeku](https://discourse.openehr.org/u/yampeku)\
**Post date:** [11 January 2012 10:46 UTC](https://discourse.openehr.org/t/bugs-in-domain-types-in-xmlserializer/15126/3 "2012-01-11T10:46:46Z")

</div>

Good to know 🙂  
I found this while I was doing a 'parser' for XML archetypes (DOM). I  
know it is not ideal (also dependent of the changes on the schema) but  
I needed to be able to parse current XML generated by XMLserializer  
(which as you said differs from the schema). Also, the schema is not  
completely correct (at least I detected missing assumed\_values and  
many parts where the java implementation of AOM/ADL parser are much  
more powerful than the schema)  
Should I update the serializer to be at least compliant with the schema?

---

<div class="post-metadata">

**Author:** ![system](https://discourse.openehr.org/uploads/default/original/2X/f/f0a1dedb20c42747bddcafd6c7df9db5f34f003c.svg) [@system](https://discourse.openehr.org/u/system)\
**Post date:** [11 January 2012 11:12 UTC](https://discourse.openehr.org/t/bugs-in-domain-types-in-xmlserializer/15126/4 "2012-01-11T11:12:38Z")

</div>

Hi Diego,

That would be great in my point of view.

For the longer term, I agree with Rong:  
I have made a couple of minor changes to the XML Serialiser in the past to improve its compliance, but you are never sure what you have missed.  
So, now you have found more inconsistencies, and this may be a (nearly) endless game without a formal mapping approach.

Sebastian

> **(attachments)**
>
> ![oceanlogo.png](https://discourse.openehr.org/images/transparent.png)

---

<div class="post-metadata">

**Author:** ![system](https://discourse.openehr.org/uploads/default/original/2X/f/f0a1dedb20c42747bddcafd6c7df9db5f34f003c.svg) [@system](https://discourse.openehr.org/u/system)\
**Post date:** [11 January 2012 12:08 UTC](https://discourse.openehr.org/t/bugs-in-domain-types-in-xmlserializer/15126/5 "2012-01-11T12:08:04Z")

</div>

That’s exactly the concern.

Diego,  
Just curious, why make a parser that is dependent on a incomplete XML serializer? If you need object model of archetypes, you could simply use the ADL parser directly.

Cheers,  
Rong

> **(attachments)**
>
> ![oceanlogo.png](https://discourse.openehr.org/images/transparent.png)

---

<div class="post-metadata">

**Author:** ![yampeku](https://discourse.openehr.org/user_avatar/discourse.openehr.org/yampeku/32/25_2.png) [@yampeku](https://discourse.openehr.org/u/yampeku)\
**Post date:** [11 January 2012 12:55 UTC](https://discourse.openehr.org/t/bugs-in-domain-types-in-xmlserializer/15126/6 "2012-01-11T12:55:25Z")

</div>

I'm working on the CIMI topic using LinkEHR transformation functionality.  
As an experiment, I loaded AOM as a reference model in LinkEHR (so we  
can create archetypes based on archetype model) 🙂  
Also, both Intermountain CEML and CiEHR CCML were loaded as data  
sources for the mapping. Those organizations have already defined a  
lot of DCM following their own schema (in XML format).  
So the idea then was to transform all the already existing DCM into  
AOM archetypes of their original model.  
Mapping each one of the DCM models as sources and using AOM as target,  
I have generated an XQuery (in this case two, one different for each  
DCM format) that generates XML archetype instances from DCM XML  
instances.  
The next obvious step is to open that XML archetype with LinkEHR to  
continue its edition 😉  
Now we can use all the archetype developed tools to work with more  
than 6000 clinical developed concepts (as the DCM models were also  
loaded as reference models, we can even edit the transformed  
archetypes).

Maybe with a graph would be clearer 🙂

---

<div class="post-metadata">

**Author:** ![Miguel\_Martinez\_de\_E](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/m/d6d6ee/32.png) [@Miguel\_Martinez\_de\_E](https://discourse.openehr.org/u/Miguel_Martinez_de_E)\
**Post date:** [11 January 2012 14:40 UTC](https://discourse.openehr.org/t/bugs-in-domain-types-in-xmlserializer/15126/7 "2012-01-11T14:40:16Z")

</div>

Hi all,  
I joint the mailing list a few days ago so, first of all, congratulations for your great development! In my oppinion, the implementation is very easy to learn and use.

I’m a newbie in OpenEHR, XSD and JAXB. I hope this is the correct place to present my doubts. In other case, my apologises and please drop this mail from your mailboxes.

Two weeks ago, I tried to implement my own RM from XSD sources found in: [http://www.openehr.org/releases/1.0.2/its/XML-schema/index.html](http://www.openehr.org/releases/1.0.2/its/XML-schema/index.html)  
The reason for doing so is to be able to use other base data types, for example, the data types defined in ISO 21090. The EHR of my project does not need to interoperate with other EHRs, but the good reason to choose OpenEhr was its good design.

Nevertheless, I found several issues:

1. It seems to me that the XSD files are incomplete or at least I haven’t found any XSD definition for some classes, for example for the EHR class.
2. I wasn’t able to build java classes from the XSD files correctly (I mean in a specific java package). I tried to tune JAXB parsing using XJB files but found several limitations (in the languaje used to define the XJB files) that didn’t allowed me to do it.
3. I have not seen a way to define constructors with JAXB in the way that they are defined in ref\_impl\_java (or it required much work).

Is there any complete XSD definition of OpenEHR?  
Is anyone trying something similar with JAXB?  
Thank you very much,  
Miguel

2012/1/11 Sebastian Garde \<[sebastian.garde@oceaninformatics.com](mailto:sebastian.garde@oceaninformatics.com)\>

---

<div class="post-metadata">

**Author:** ![yampeku](https://discourse.openehr.org/user_avatar/discourse.openehr.org/yampeku/32/25_2.png) [@yampeku](https://discourse.openehr.org/u/yampeku)\
**Post date:** [16 January 2012 09:02 UTC](https://discourse.openehr.org/t/bugs-in-domain-types-in-xmlserializer/15126/8 "2012-01-16T09:02:06Z")

</div>

The things missing on the AOM schema (assumed\_values, lists...) should  
be discussed on this list or is more an issue of the technical list?

---

<div class="post-metadata">

**Author:** ![system](https://discourse.openehr.org/uploads/default/original/2X/f/f0a1dedb20c42747bddcafd6c7df9db5f34f003c.svg) [@system](https://discourse.openehr.org/u/system)\
**Post date:** [16 January 2012 09:31 UTC](https://discourse.openehr.org/t/bugs-in-domain-types-in-xmlserializer/15126/9 "2012-01-16T09:31:59Z")

</div>

Since they are not java-specific issues, I would think they are better  
discussed on the technical list.

/Rong

---

<div class="post-metadata">

**Author:** ![yampeku](https://discourse.openehr.org/user_avatar/discourse.openehr.org/yampeku/32/25_2.png) [@yampeku](https://discourse.openehr.org/u/yampeku)\
**Post date:** [16 January 2012 09:37 UTC](https://discourse.openehr.org/t/bugs-in-domain-types-in-xmlserializer/15126/10 "2012-01-16T09:37:35Z")

</div>

Ok, I'll post it right now 🙂

---

<div class="post-metadata">

**Author:** ![system](https://discourse.openehr.org/uploads/default/original/2X/f/f0a1dedb20c42747bddcafd6c7df9db5f34f003c.svg) [@system](https://discourse.openehr.org/u/system)\
**Post date:** [16 January 2012 09:38 UTC](https://discourse.openehr.org/t/bugs-in-domain-types-in-xmlserializer/15126/11 "2012-01-16T09:38:27Z")

</div>

Hi Miguel,

Thanks for the kind words. Please find my comments below.

Regards,  
Rong

2012/1/11 Miguel Martínez de Espronceda Cámara \<[miguel.martinezdeespronceda@unavarra.es](mailto:miguel.martinezdeespronceda@unavarra.es)\>

> Hi all,  
> I joint the mailing list a few days ago so, first of all, congratulations for your great development! In my oppinion, the implementation is very easy to learn and use.
> 
> I’m a newbie in OpenEHR, XSD and JAXB. I hope this is the correct place to present my doubts. In other case, my apologises and please drop this mail from your mailboxes.
> 
> Two weeks ago, I tried to implement my own RM from XSD sources found in: [http://www.openehr.org/releases/1.0.2/its/XML-schema/index.html](http://www.openehr.org/releases/1.0.2/its/XML-schema/index.html)  
> The reason for doing so is to be able to use other base data types, for example, the data types defined in ISO 21090. The EHR of my project does not need to interoperate with other EHRs, but the good reason to choose OpenEhr was its good design.
> 
> Nevertheless, I found several issues:
> 
> 1. It seems to me that the XSD files are incomplete or at least I haven’t found any XSD definition for some classes, for example for the EHR class.

The XSD files can be found there [http://www.openehr.org/releases/1.0.2/its/XML-schema/index.html](http://www.openehr.org/releases/1.0.2/its/XML-schema/index.html)

> 1. I wasn’t able to build java classes from the XSD files correctly (I mean in a specific java package). I tried to tune JAXB parsing using XJB files but found several limitations (in the languaje used to define the XJB files) that didn’t allowed me to do it.
> 2. I have not seen a way to define constructors with JAXB in the way that they are defined in ref\_impl\_java (or it required much work).

The xml-binding component from the java project provides bi-directional mapping between RM objects and XSD-generated java objects. It’s based on XMLBeans similar to JAXB.  
[http://www.openehr.org/svn/ref\_impl\_java/TRUNK/xml-binding/](http://www.openehr.org/svn/ref_impl_java/TRUNK/xml-binding/)