Greetings, Did I get this right? There are XSDs on openEHR web site. There are also XSDs which are different than the first set, provided by LinkEHR. If these are XSDs of the published parts of the openEHR specifications, such as RM or AOM, then there should only be one XSD set, published by openEHR. If the XSDs belong to parts which are not part of the openEHR specs, having more than one XSD theoretically would not hurt interoperability, since they are not openEHR XSDs until they're published by the foundation, but in practice, this would be a problem waiting to emerge in the future. Am I missing something here? Multiple XSDs sounds like a big can of worms to me.
Best regards Seref On Mon, Nov 26, 2012 at 5:02 PM, Bert Verhees <bert.verhees at rosa.nl> wrote: > Thanks Athanasios and Diego, > > It is easier to download then to write it myself ;-) > > But still I wonder why the OpenEHR-community is not offering these. > > cheers > Bert > > > > > On 11/26/2012 05:51 PM, Diego Bosc? wrote: > >> Hello Bert, >> >> We created a XML Schema for the demographics part some time ago. You >> can download it from here. >> >> http://pangea.upv.es/linkehr/**wp-content/uploads/2009/03/** >> Demographics.xsd<http://pangea.upv.es/linkehr/wp-content/uploads/2009/03/Demographics.xsd> >> >> Regards >> >> 2012/11/26 Bert Verhees <bert.verhees at rosa.nl>: >> >>> 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. >>> >>> 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. >>> 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. >>> >>> 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. >>> 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. >>> >>> Thanks >>> Bert Verhees >>> >>> >>> >>> ______________________________**_________________ >>> openEHR-technical mailing list >>> openEHR-technical at lists.**openehr.org<openEHR-technical at >>> lists.openehr.org> >>> http://lists.openehr.org/**mailman/listinfo/openehr-** >>> technical_lists.openehr.org<http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org> >>> >> ______________________________**_________________ >> openEHR-technical mailing list >> openEHR-technical at lists.**openehr.org<openEHR-technical at >> lists.openehr.org> >> http://lists.openehr.org/**mailman/listinfo/openehr-** >> technical_lists.openehr.org<http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org> >> > > > ______________________________**_________________ > openEHR-technical mailing list > openEHR-technical at lists.**openehr.org<openEHR-technical at > lists.openehr.org> > http://lists.openehr.org/**mailman/listinfo/openehr-** > technical_lists.openehr.org<http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20121126/28922bb2/attachment.html>
