# CKM Archetypes in XML don't seem to validate properly against available XSDs **Category:** [Technical (archive)](https://discourse.openehr.org/c/technical-archive/156) **Created:** 2011-09-05 17:28 UTC **Views:** 5 **Replies:** 11 **URL:** https://discourse.openehr.org/t/ckm-archetypes-in-xml-dont-seem-to-validate-properly-against-available-xsds/15082 --- ## Post #1 by @ANASTASIOU_A1 Hello everyone Maybe there has been some intermediate change that i am missing here but i am trying to validate "openEHR\-EHR\-OBSERVATION\.blood\_pressure\.v1\.xml" \(downloaded as XML from the CKM editor today\) through the available XSDs from http://www.openehr.org/releases/1.0.2/its/XML-schema/index.html and i am getting a very large number of errors\. Just as an indication, all the errors are "Invalid content was found" mostly for the elements "existence" and "lower\_included" \(expecting "rm\_attribute\_name" and "lower\_unbounded" respectively\) Are there different XSDs for the structure of the CKM XML files? And if yes, are they available? Looking forward to hearing from you Athanasios Anastasiou P\.S\. Just as a note, "Resource\.xsd" references "basetypes\.xsd" instead of "BaseTypes\.xsd" in both 1\.0\.1 and 1\.0\.2 versions \(while it was "BaseTypes\.xsd" in version 1\.0\)\. It seems that the intention is to preserve the letter case \(e\.g\. the "Resource\.xsd" and "Structure\.xsd" reference "BaseTypes\.xsd"\)\. It's a tiny thing but, as you know, it makes a difference for case sensitive file systems :\-\) --- ## Post #2 by @system Hi CKM is using the XML serialiser of the openEHR Java Reference implementation\. It seems that the serialiser applies a different order to some elements than required by the schema\. Not sure if these were turned around in the xsd at some stage maybe? While I don't really understand why these elements need to have an order, I believe the problem in the XML serialiser is quite easy to fix\. Is anybody maintaining this code at present? Otherwise I can have a go\. Regards Sebastian --- ## Post #3 by @system Hi Sebastian, To my knowledge, no one is maintaining the AOM xml-serialiser from the Java Reference Project at the moment. So I would appreciate if you could fix it this time. Actually the larger issue about xml-serialiser is that it's not relying on a java XML binding API. This makes it vulnarable to changes in the archetype XML schema. There is already a xml-binding component that provides XML parsing and serialising based on RM XML schema. One just needs to implement a mapping between the classes from openehr-aom component and the generated XML binding classes in order to have XML schema based parsing and serialising. This is probably the best way to go. Cheers, Rong --- ## Post #4 by @Seref Hi Rong, I'm working on this; an AOM to JAXB binding\. I'm hoping that I'll be able to give more details in a couple of weeks\. Regards Seref --- ## Post #5 by @ANASTASIOU_A1 Hello Thank you for your response Sebastian\. Is it a small number of changes that i could perhaps apply to the XSDs temporarily or better wait for you to modify the serialiser and try to re\-download the archetypes from the CKM? All the best Athanasios Anastasiou --- ## Post #6 by @system I believe it would be a very limited number of changes. If this helps you temporarily, I'd go for it. Sebastian [details="(attachments)"] ![oceanlogo.png|84x82](upload://2EtFgZ1bS4JNl1d51FusTB7hg8M.png) [/details] --- ## Post #7 by @system Hi, I have modified the XMLSerialiser code and checked it in, you can compile it from there if you like. This will become part of the next minor release for ckm. Seref: looking forward to the binding! Cheers Sebastian [details="(attachments)"] ![oceanlogo.png|84x82](upload://2EtFgZ1bS4JNl1d51FusTB7hg8M.png) [/details] --- ## Post #8 by @system Thanks, Sebastian! yes, I also look forward to the new AOM/XML binding component. Cheers, Rong [details="(attachments)"] ![oceanlogo.png|84x82](upload://2EtFgZ1bS4JNl1d51FusTB7hg8M.png) [/details] --- ## Post #9 by @system Hi Athanasios, I have updated CKM, hopefully fixing this issue\. Let me know if this is working for you now Regards Sebastian --- ## Post #10 by @ANASTASIOU_A1 Hello Sebastian First of all, many thanks for the quick response\. I have just given it one more try and it generates less errors: The complaints currently are: "No child element expected at this point" for "property" and "terminology\_id" and that C\_CODE\_PHRASE and C\_DV\_QUANTITY can not be resolved because "the type definition can not be abstract for element children"\. I hope this helps\. All the best Athanasios --- ## Post #11 by @system Hi, Is it possible that these errors occur because you are using archetype.xsd as your top-level schema? In that case, try using the OpenehrProfile.xsd as the top-level schema instead (which then includes the archetype.xsd). The openehr profile defines the extra C_CODE_PHRASE and C_DV_QUANTITY (and a couple others) Cheers Sebastian [details="(attachments)"] ![oceanlogo.png|84x82](upload://2EtFgZ1bS4JNl1d51FusTB7hg8M.png) [/details] --- ## Post #12 by @ANASTASIOU_A1 Hello Sebastian Many thanks, that was indeed the problem\. I thought all necessary data structures would be referenced through the "Archetype\.xsd" at some point\. All the best Athanasios Anastasiou --- **Canonical:** https://discourse.openehr.org/t/ckm-archetypes-in-xml-dont-seem-to-validate-properly-against-available-xsds/15082 **Original content:** https://discourse.openehr.org/t/ckm-archetypes-in-xml-dont-seem-to-validate-properly-against-available-xsds/15082