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 <bert.verhees at rosa.nl > <mailto: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 > <mailto: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 > <mailto: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 > <mailto: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 > <mailto: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/20121127/55726e6a/attachment.html>
