Hi Seref, The XML Schema standard 1.1 has no problem with having multiple files for one definition-set. You can find them linked from the specifications-1.0.2-page.
Bert Verstuurd vanaf mijn iPad Op 26 nov. 2012 om 18:13 heeft Seref Arikan <serefarikan at kurumsalteknoloji.com> het volgende geschreven: > 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 >>> >>> 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 >>>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >>> _______________________________________________ >>> openEHR-technical mailing list >>> openEHR-technical at lists.openehr.org >>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> >> >> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical at lists.openehr.org >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at 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/1bee47a3/attachment.html>
