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
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.
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.
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?
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.
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".
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)
