# Questions about the XSD-files. **Category:** [Technical (archive)](https://discourse.openehr.org/c/technical-archive/156) **Created:** 2012-11-26 16:36 UTC **Views:** 3 **Replies:** 37 **URL:** https://discourse.openehr.org/t/questions-about-the-xsd-files/13526 --- ## Post #1 by @system 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 --- ## Post #2 by @yampeku 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 --- ## Post #3 by @ANASTASIOU_A1 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 --- ## Post #4 by @system 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 --- ## Post #5 by @Seref 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 --- ## Post #6 by @system 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 --- ## Post #7 by @Tim_Cook2 Hi Seref, The openEHR schemas have been there for many years. [http://www.openehr.org/releases/1.0.2/its/XML-schema/index.html](http://www.openehr.org/releases/1.0.2/its/XML-schema/index.html) --Tim --- ## Post #8 by @system Hi Seref Only one XSD set from openEHR. If we upgrade it has to be formal. Cheers, Sam --- ## Post #9 by @Seref I think I misunderstood the original question. Thanks for all the responses everyone. Best regards Seref --- ## Post #10 by @system 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 --- ## Post #11 by @Heath_Frankel3 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 --- ## Post #12 by @system (I leave this notice so people understand the torture I went through, while replying to this email) > 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 > > 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. > > __*[HKF: ]*__ __*What did you comment out, the entire element?*__ that line is the complete and only global element in this file, and I commented that out, but I added global elements in this file for every type-construct representing a concrete class. > __*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?*__ I don't think you should serialize an item_structure as root because it is abstract. There can never be an XML instance of item_structure, and XML Schema's are to define and validate XML instances and their appearance. Of course I can comment it out if I want, I can do whatever I want, but I want to conform as much as possible to the OpenEhr specs, even if I do not always agree. That is why I bring it to discussion, that is why I am glad that the XSD is formally maintained by the foundation, as Seref and Sam indicate. > 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 am afraid that I don't understand how that works. In my opinion, there must be an global element declaration for every class which can be used as root. This is what I suggested as alternative for this construct which I don't understand. For all the classes derived from item_structure, there is no global element defined. > 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.*__ There you have a good point, I suggested that also, although, I think the overhead is minimal. It was just for convenience that I did my suggestion and XML schema's are not for convenience. So, I think your position in this is reasonable. Let's forget point 3. > 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 t*____*he EHR focus of the specs. I also have a schema that could be used, I may have already put it up in Jira.*__ The specs have demographics defined, so, in my opinion, the demographics XSD should be there. Do you mean, in your last comment, that you put it in Jira, and that that demographics XSD will arrive? Thanks for your reply Bert --- ## Post #13 by @thomas.beale I think it just did ;\-\) Early in 2013, the specifications will be start being revamped\. That will be an opportunity for people to offer & improve changes and updates to existing specifications\. \- thomas --- ## Post #14 by @system Why didn't the website offer this XSD, for so many years\. It is especially important because Sam and Seref stress the importance of the XSD and that they are maintained in formal way\. That I never realized\. Under these circumstances it almost begins to look like a statement, but I couldn't imagine what\. So it is just a small question, but it seems hard to answer\. But early 2013 is very near, so I will be patient :\) I can live with the XSD from Diego, which looks very well made\. Thanks again Diego\. regards Bert Verhees --- ## Post #15 by @Heath_Frankel3 Bert, You can define elements to be type of an abstract type allowing any concrete subtype in an instance. This is the intent of the items element, to allow any rotatable concrete type to be represented in a document with root element of items. Heath --- ## Post #16 by @system Op 27\-11\-2012 9:07, Heath Frankel schreef: > > Bert, > You can define elements to be type of an abstract type allowing any concrete subtype in an instance\. This is the intent of the items element, to allow any rotatable concrete type to be represented in a document with root element of items\. > Heath > Hi Heath, You can just have one globally element from Locatable in the XSD, and say that XML\-instances must comply to that\. \(just joking\) --- ## Post #17 by @Heath_Frankel3 Bert, Items is not a class, it is an attribute. Heath --- ## Post #18 by @Heath_Frankel3 Bert, The rule you reference says nothing about concrete types. As far as I am concerned the items element is satisfying this rule. You are welcome to change the schema in your system as you see fit just as linkEHR have done, but I suggest any additional element declarations are done in a different namespace otherwise you will be producing incompatible instances. I am still not understanding you issues with this element other than styling. If you have any technical issue please raise a jira issue. Heath --- ## Post #19 by @system > Bert, > Items is not a class, it is an attribute. exactly my idea, it is not an attribute in XSD context, but in class context. from which class is it an attribute? Bert --- ## Post #20 by @system " i am still not understanding you issues with this element other than styling\. If you have any technical issue please raise a jira issue" I still don't understand what humanity did wrong that we need to be punished with iPads, my wife remove all computers from the living space, and bought iPads\. I don't have a Jira account at your site, if I have, I post my XSD's as a proposition\. Thanks Bert\. --- ## Post #21 by @Heath_Frankel3 CLUSTER for one. The XML ITS of the RM is not a pure representation of the RM. Design decisions needed to be made, this is one of them. If you have a problem with it raise a jira issue. Heath --- ## Post #22 by @Seref I'll attempt to comment on Bert's problem, hoping I understand it :) When you do not have a root element definition in an XSD, you can't create XML documents which will be valid according to that XSD. What Bert is saying is, if we had a bunch of root elements in the XSDs, it would allow us create valid XML with these root elements. At the moment, if you create an XML element with a DVQuantity subclass as the root, it would not be valid according to XSD, because the XSD does not explicitly list DvQuantity as a root element As it is, the XSDs define larger units of documents, and having finer granularity requires having more root elements defined as options in the XSDs. Bert, did I get it? --- ## Post #23 by @Peter_Gummer1 Bert Verhees wrote: > I don't have a Jira account at your site, if I have, I post my XSD's as a proposition\. Hi Bert, > From the openehr\.org home page, there's a link to http://www.openehr.org/issues/secure/Dashboard.jspa, where you can sign up for an account\. Peter --- ## Post #24 by @system thanks, Peter, I will work on it tomorrow\. Bert --- ## Post #25 by @system > Bert, > The rule you reference says nothing about concrete types. As far as I am concerned the items element is satisfying this rule. Hi Heath, only concrete classes can be instantiated in XML. Bert --- ## Post #26 by @system Hi Heath, take a look at items in CLUSTER, it is declared as a local element. Bert --- ## Post #27 by @Heath_Frankel3 Seref, The items element is provided in the structure.xsd for this very reason but Bert seems to object to it because of its name or its type or some other reason that I have not yet determined. Heath --- ## Post #28 by @Heath_Frankel3 True, but you can declare elements in an xsd as an abstract type allowing any concrete type to be provided in an xml document where the concrete type is specified using the xs:type attribute. For example: ... Heath --- ## Post #29 by @system I give up, I don't know what is happening over there, but it takes for me too much time. I build my own XSD and forget the one OpenEHR offers. (in fact, I have them ready, I just wanted to discuss my knowledge in the OpenEHR community, and see if we can work together) Best regards Bert Verhees --- ## Post #30 by @system Seref, I had originally 3 questions/remarks: \- having the root elements \- why not remove that "items" line \- where is the demographic\.xsd I also had 4th question, but I dropped that, that was my mistake\. --- ## Post #31 by @system Seref, I had originally 3 questions/remarks: \- having the root elements \- why not remove that "items" line \- where is the demographic\.xsd I also had 4th question, but I dropped that, that was my mistake\. --- ## Post #32 by @system Hi\! I see several use cases for sending and storing XML pieces smaller than compositions etc as valid XML documents\. What about creating a separate \(but official\) file with those root elements in the same namespace as the other schema components? That way implementers can choose if they want that part or not\. Can you create a draft of such a file Bert and post it on the wiki or mailing list? Also, what is needed to turn the LinkEHR demographics XSD into an official openEHR one? \(Technically and process\-wise\.\.\.\) // Erik P\.s\. Bert, I think you may have interpreted the tone of some comments/replies as more hostile than they were intended by the senders\. It is sometimes hard to understand what you and others asking for so it takes some rounds of questions to clarify that\. >> When you do not have a root element definition in an XSD, you can't create >> XML documents which will be valid according to that XSD\. What Bert is saying >> is, if we had a bunch of root elements in the XSDs, it would allow us create >> valid XML with these root elements\. \[\.\.\.\] > I just want root\-elements for every concrete class which can be root in a > XML\-instantiation\. \[\.\.\.\] --- ## Post #33 by @system If so, I want to excuse for that\. Bert --- ## Post #34 by @yampeku I didn't realize that the XSD file has no license\. Please assume a CC\-BY license, which is the same we use for 13606 schemas\. --- ## Post #35 by @Heath_Frankel3 Bert, I too was sharing my knowledge, as one of the authors of the schema whether they are classed as good or bad, I thought it was worth the effort explaining the design rationale. I apologise for wasting your time and will choose more wisely in future where I spend mine. Heath --- ## Post #36 by @system ;\) Bert --- ## Post #37 by @system ;\) Bert --- ## Post #38 by @thomas.beale I'm unclear on the outcome of this confusing discussion\. For the lack of demographic XSD, what should be used is an XSD that is compatible with the existing ones\. For the other questions, they're at a level of detail I don't know in XSD\. But they should be answerable one way or the other\. So the answer to these questions for the 1\.0\.2 schemas should be pretty objective\. There are known problems & shortcomings with the 1\.0\.2 XSDs, so in my view, the most interesting question is what better schemas would look like in the next release\. There has been thinking about that on the past\. \- thomas --- **Canonical:** https://discourse.openehr.org/t/questions-about-the-xsd-files/13526 **Original content:** https://discourse.openehr.org/t/questions-about-the-xsd-files/13526