Hi Bert, Sorry but I struggled to understand the issue you have below. Would you mind looking at my comments below and see if I have understood them correctly?
Heath -----Original Message----- From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On Behalf Of Bert Verhees Sent: Tuesday, 27 November 2012 3:07 AM To: For openEHR technical discussions Subject: Questions about the XSD-files. Hi, I was studying the OpenEHR XSD files, I found they validate fine against Saxon-EE 1.0 and 1.1 But I have a few points which are not clear to me. 1) In the Structure.xsd I find this line, I don't know why it is there. <xs:element name="items" type="LOCATABLE"/> I commented it out, and it still validates fine. [HKF: ] What did you comment out, the entire element? Although this is not necessary when you have a composition instance, if you want to serialize an ITEM_STRUCTURE as a root of an XML document perhaps for a query result or internal application purposes then this gives you a standard schema element to do this. If you don't use it then commenting out will not hurt. What is the problem with its existence? 2) There were some more things in the same file. There were no element-declarations to the concrete classes, like ITEM_TREE, CLUSTER, and so on. [HKF: ] The element above is used for all these subtypes. I would expect them because there are also archetypes in CKM based on these classes/elements and can be instantiated in XML. I added them, and now I can generate example XML with these classes as root, which was not possible before. [HKF: ] It was if you used the items element above. 3) It would be nice to have elements in the base-types XSD too. There is no need for it in the OpenEHR implementation, because they will never be root-element, but it is good to see their XML-structure isolated, for convenience. [HKF: ] Are you talking about DATA_VALUE types or everything? Personally I don't see the value it would add overhead n the in memory schema objects used for validation. I will try that and see if they will be a problem. 4) And the last point is, I missed the Demographics.xsd, although these RM-classes are also archetypeable and can lead too to XML-instances. [HKF: ] Yeah, I guess that shows the EHR focus of the specs. I also have a schema that could be used, I may have already put it up in Jira. Thanks Bert Verhees _______________________________________________ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.or g -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20121127/ac7c080c/attachment.html>
