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
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?
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 =)
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?
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.
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.
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).
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
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:
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.
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.
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
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
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:
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.
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.
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).
