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 On 07/09/2011 12:38, Sebastian Garde wrote: > 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 > > Am 07.09.2011 13:13, schrieb Athanasios Anastasiou: >> 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 >> >> >> >> On 07/09/2011 11:04, Sebastian Garde wrote: >>> Hi Athanasios, >>> >>> I have updated CKM, hopefully fixing this issue. >>> Let me know if this is working for you now >>> >>> Regards >>> Sebastian >>> >>> >>> Am 06.09.2011 11:49, schrieb Athanasios Anastasiou: >>>> 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 >>>> >>>> >>>> >>>> >>>> On 06/09/2011 09:53, Sebastian Garde wrote: >>>>> 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 >>>>> >>>>> >>>>> Am 05.09.2011 19:28, schrieb Athanasios Anastasiou: >>>>>> 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 :-) >>>>>> >>> >> > > -- > Ocean Informatics > Dr Sebastian Garde > Senior Developer > Ocean Informatics > > /Dr. sc. hum., Dipl.-Inform. Med, FACHI/ > > Skype: gardeseb >
