Looks good to me, The only issues I am hitting so far are due to the original ADL
e.g. openEHR-EHR-OBSERVATION.dimensions.v1.adl defines at0013 (Object: The object, axis or body part that is being measured) as a DV_CODED_TEXT but without associated codes. I don't know if it is helpful if I highlight those type of anomolies (or perhaps not anonomolies, just my misunderstanding of the definition). thanks! Greg http://www.patientos.org On 11/7/07, Heath Frankel <heath.frankel at oceaninformatics.com> wrote: > Greg and others, > We have configured an auto-build process to convert the ADL archetypes to > XML located at http://svn.openehr.org/knowledge/archetypes/dev. They now > all exist and are valid against the RM 101 XML Schema. Let me know if you > find any issues with the XML content. > > Regards > > Heath > > > -----Original Message----- > > From: Heath Frankel [mailto:heath.frankel at oceaninformatics.com] > > Sent: Wednesday, 7 November 2007 11:06 AM > > To: 'For openEHR technical discussions' > > Subject: RE: XML versions of the ADL > > > > Greg, > > I agree with Tim, that you can't always expect Ocean to provide these > tools. > > We just happen to be one of the main contributors to the openEHR > foundation. > > As Tim said, the openEHR specs are the normative artefacts including the > XML > > schemas provided at http://svn.openehr.org/specification/TAGS/Release- > > 1.0.1/ITS/XML-schema. As for the archetypes, the ADL is probably the best > > source of truth but even then there are some archetypes that have some > errors > > left over from previous versions of ADL and Editor tools. > > > > The XML archetypes have been generated using the Ocean Archetype Editor > which > > is available free from > > http://downloads.oceaninformatics.com/products/ArchetypeEditor. The XML > > archetypes provided in > > http://svn.openehr.org/knowledge/archetypes/dev/xml are currently manually > > generated using an old version of the editor and committed to subversion. > > This is why a complete set is not available. These XML archetypes are NOT > > valid against the openEHR R1.0.1 archetype and openehrprofile XML schemas, > > they do not even use the correct namespace. They have not been updated > since > > R1.0.1 was release. > > > > Ocean has provided a auto-generation process for the NHS archetypes which > > generate valid R1.0.1 XML and we will endeavour to provide this for the > dev > > archetypes as well. BTW, I have noticed an error in the term bindings XML > and > > will have this rectified ASAP. > > > > You could use the Ocean Archetype Editor to produce the required XML > yourself. > > A similar error as mentioned above exists for term bindings but more > critical > > as it does not produce valid XML when an archetype includes term bindings. > > Again I will have this rectified ASAP. > > > > I will provide some background on the automated XML conversion process. > The > > ADL archetype is read using openEHR Eiffel ADL Parser reference > implementation > > which generates Archetype Object Model representation of the archetype. > Using > > the openEHR Archetype Model XML Schema based on the AOM we simply > serialise > > this AOM representation to XML. > > > > One of the issues you have highlighted is in regard to namespace prefixes. > > The Ocean serialiser uses the openEHR AM schema namespace as the default > > namespace and hence does not require prefixes. The LiU Editor obviously > uses > > an at namespace prefix. Both are completely valid XML. > > > > The second issue is the xsi:type of children. Look at the > openehrprofile.xsd > > and you will see that C_DV_QUANTITY is the correct type. This is > consistent > > with the openEHR profile specification. > > > > Thirdly, both DvQuantity and QUANTITY are wrong in this case. It should > be > > DV_QUANTITY as per the openEHR RM. The Ocean Archetype Editor now > produces > > this correctly and the XML converter used to generate the NHS XML > archetype is > > working correctly in this case, see > > http://svn.openehr.org/knowledge/archetypes/dev-uk- > > nhs/gen/xml/openehr/ehr/entry/observation/openEHR-EHR- > > OBSERVATION.blood_pressure.v1.xml. > > > > Hope this helps. > > > > Regards > > > > Heath > > > > > > > -----Original Message----- > > > From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- > > > bounces at openehr.org] On Behalf Of Greg Caulton > > > Sent: Tuesday, 6 November 2007 8:05 AM > > > To: For openEHR technical discussions > > > Subject: XML versions of the ADL > > > > > > In writing some code to parse the XML to populate my database I notice > > > there is not always a matching XML on subversion for a given ADL. > > > > > > For example there is > > > > > > > > > http://svn.openehr.org/knowledge/archetypes/dev/adl/openehr/ehr/entry/observ > at > > > ion/openEHR-EHR-OBSERVATION.blood_pressure.v1.adl > > > > > > > > > http://svn.openehr.org/knowledge/archetypes/dev/xml/openehr/ehr/entry/observ > at > > > ion/openEHR-EHR-OBSERVATION.blood_pressure.v1.xml > > > > > > > > > but not an XML for > > > > > > > > > http://svn.openehr.org/knowledge/archetypes/dev/adl/openehr/ehr/entry/observ > at > > > ion/openEHR-EHR-OBSERVATION.respiration.v1.adl > > > > > > > > > To get around this I started to use the LiU Archetype Editor but I > > > realize now it generates a different XML than on subversion. For > > > example the LiU editor generates nodes with type > > > > > > <children xsi:type="at:C_QUANTITY"> > > > <rm_type_name>DvQuantity</rm_type_name> > > > > > > but on subversion it has > > > > > > <children xsi:type="C_DV_QUANTITY"> > > > <rm_type_name>QUANTITY</rm_type_name> > > > > > > > > > Is the XML unreliable such that I must use a Java ADL parser? > > > > > > thanks! > > > > > > Greg > > > _______________________________________________ > > > openEHR-technical mailing list > > > openEHR-technical at openehr.org > > > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > > > > > > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >
