# bugs in domain types in XMLserializer **Category:** [Reference Implementation: Java (archive)](https://discourse.openehr.org/c/reference-implementation-java-archive/154) **Created:** 2012-01-09 08:23 UTC **Views:** 17 **Replies:** 10 **URL:** https://discourse.openehr.org/t/bugs-in-domain-types-in-xmlserializer/15126 --- ## Post #1 by @yampeku 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\) \{            printList\(cdatetime\.getList\(\), out\);        \} 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 --- ## Post #2 by @system 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 --- ## Post #3 by @yampeku 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? --- ## Post #4 by @system 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 [details="(attachments)"] ![oceanlogo.png|84x82](upload://2EtFgZ1bS4JNl1d51FusTB7hg8M.png) [/details] --- ## Post #5 by @system 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 [details="(attachments)"] ![oceanlogo.png|84x82](upload://2EtFgZ1bS4JNl1d51FusTB7hg8M.png) [/details] --- ## Post #6 by @yampeku 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 :\) --- ## Post #7 by @Miguel_Martinez_de_E 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. 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. 1. 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)> --- ## Post #8 by @yampeku 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? --- ## Post #9 by @system Since they are not java\-specific issues, I would think they are better discussed on the technical list\. /Rong --- ## Post #10 by @yampeku Ok, I'll post it right now :\) --- ## Post #11 by @system 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. > 1. 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/) --- **Canonical:** https://discourse.openehr.org/t/bugs-in-domain-types-in-xmlserializer/15126 **Original content:** https://discourse.openehr.org/t/bugs-in-domain-types-in-xmlserializer/15126