Questions about the XSD-files.
Hi Sam and Seref, Both of you indicate that maintenance of the XSD has to be done formally by the foundation. This good news, then there will be only a single answer possible for the four questions I started this thread with. thanks, Bert Verstuurd vanaf mijn iPad Op 26 nov. 2012 om 22:46 heeft Sam Heard het volgende geschreven: > Hi Seref > Only one XSD set from openEHR. If we upgrade it has to be formal. > Cheers, Sam > > On 27/11/2012 2:43 AM, Seref Arikan wrote: >> 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 >> 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 : >>>>> 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. >>>>> >>>>> >>>>> 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 > > ___ > 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/ded3af23/attachment.html>
Questions about the XSD-files.
ailman/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>> 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 >> >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> > > > > -- > > Timothy Cook, MSc +55 21 94711995 > MLHIM http://www.mlhim.org > LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook > Academic.Edu Profile: http://uff.academia.edu/TimothyCook > Google Scholar: http://goo.gl/MMZ1o > > ___ > 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/c87f22b2/attachment-0001.html>
Questions about the XSD-files.
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 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 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 : >>>> 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. >>>> >>>> >>>> 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>
Questions about the XSD-files.
Hi Seref, The openEHR schemas have been there for many years. http://www.openehr.org/releases/1.0.2/its/XML-schema/index.html --Tim On Mon, Nov 26, 2012 at 3:13 PM, Seref Arikan < serefarikan at kurumsalteknoloji.com> wrote: > 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 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 : >>> >>>> 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. >>>> >>>> >>>> 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>>> 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>> 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> 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 > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > -- Timothy Cook, MSc +55 21 94711995 MLHIM http://www.mlhim.org LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook Academic.Edu Profile: http://uff.academia.edu/TimothyCook Google Scholar: http://goo.gl/MMZ1o -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20121126/1445af0d/attachment-0001.html>
Questions about the XSD-files.
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 : >> 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. >> >> >> 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
Questions about the XSD-files.
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 : > 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. > > > 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
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. 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
Questions about the XSD-files.
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 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 : >> >>> 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. >>> >>> >>> 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>> 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> 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 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>
Questions about the XSD-files.
Dear Bert As far as (4) is concerned, i have been using linkEHR's XSD from: http://pangea.upv.es/linkehr/?page_id=10 hope this helps All the best Athanasios Anastasiou On 26/11/2012 16:36, Bert Verhees wrote: > 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. > > > 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
