Hi Leonardo, yes that is the tagged "stable" version. I don't think there is a precompiled version of the latest trunk and you would need to compile from the trunk following the instructions here: http://www.openehr.org/wiki/display/projects/Quick+start+guide+for+the+openEHR+Java+project
Sebastian Leonardo Moretti wrote: > I'm using the jars found on > http://www.openehr.org/wiki/display/projects/Java+Project+Download > > Is there a new release of these jars? Where can I download it? > > Thanks > leo > > > Sebastian Garde-2 wrote: > >> Leo, >> >> In that case, you are probably using an older version of the Serialiser. >> This has been fixed in Rev 504 earlier this year. >> >> See e.g. the APGAR score archetype at >> http://openehr.org/knowledge/OKM.html#showArchetype_1013.1.172_7 >> >> Regards >> Sebastian >> >> Leonardo Moretti wrote: >> >>> Moreover, >>> XMLSerializer.output() produces xml fragments for DV_ORDINAL like this: >>> <children xsi:type="C_DV_ORDINAL"> >>> <rm_type_name>DvOrdinal</rm_type_name> ... >>> >>> while I'm expecting to have this >>> <children xsi:type="C_DV_ORDINAL"> >>> <rm_type_name>DV_ORDINAL</rm_type_name> .... >>> >>> >>> Probably XMLSerializer is not so compliant with the standard.. >>> >>> Regards >>> leo >>> >>> >>> >>> Sebastian Garde-2 wrote: >>> >>> >>>> Hi Leonardo, >>>> >>>> CKM is using the Java XML Serialiser to generate the XML presentation, >>>> so it is no surprise you are seeing the same effect there. >>>> >>>> I would see the Schemas as the source of truth. >>>> If it is a sequence in the schema then I believe that the order cannot >>>> simply be changed in the XML. >>>> >>>> So, my opinion is that the XML Serialiser is probably wrong here >>>> (although you may ask how much this order actually matters, practically >>>> and theoretically) >>>> >>>> Mattias Forss (who developed the XML Serialiser I believe), Eric >>>> Sundvall or Rong Chen may be able to expand on it? >>>> >>>> Regards >>>> Sebastian >>>> >>>> Moretti Leonardo wrote: >>>> >>>> >>>>> XMLSerializer.output() (xml-serializer-1.0.1.jar) produce XMLs that are >>>>> not compliant with openEHR XML-Schemas >>>>> (http://www.openehr.org/releases/1.0.2/its/XML-schema/index.html). >>>>> Also the xml representation taken from http://openehr.org/knowledge/ >>>>> are >>>>> not valid XML instances respect to these schemas (for example >>>>> <http://jira.noemalife.loc:8080/secure/attachment/15267/openEHR-EHR-OBSERVATION.body_weight.v1.adl> >>>>> >>>>> openEHR-EHR-OBSERVATION.body_weight.v1 >>>>> <http://jira.noemalife.loc:8080/secure/attachment/15267/openEHR-EHR-OBSERVATION.body_weight.v1.adl>). >>>>> >>>>> The main problem is that the order of the elements is not equals to >>>>> that >>>>> one specified in <xs:sequence> blocks of XSDs. >>>>> >>>>> What is "wrong", the implementation or the schemas? The order of the >>>>> elements in xml representation of an archetype must be fixed? >>>>> >>>>> Thanks >>>>> leo >>>>> >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> openEHR-technical mailing list >>>> openEHR-technical at openehr.org >>>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >>>> >>>> >>>> >>>> >>> >>> >> -- >> >> Ocean Informatics >> Dr Sebastian Garde >> Senior Developer >> Ocean Informatics >> >> /Dr. sc. hum., Dipl.-Inform. Med, FACHI/ >> >> Skype: gardeseb >> >> >> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical at openehr.org >> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >> >> >> > > -- Ocean Informatics Dr Sebastian Garde Senior Developer Ocean Informatics /Dr. sc. hum., Dipl.-Inform. Med, FACHI/ Skype: gardeseb -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20100514/2242ea3d/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: oceanlogo.png Type: image/png Size: 5677 bytes Desc: not available URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20100514/2242ea3d/attachment.png>
