Questions about the XSD-files.
Bert, Items is not a class, it is an attribute. Heath On Nov 27, 2012 8:50 PM, Bert Verhees bert.verhees at rosa.nl wrote: 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) There is no other globally defined element in the structures.xsd, so there is no other root-element. Every valid XML-instance has one (only one) root-element. So, many schema-processors need at least one root-element in the XSD for validation-purpose, and the XML instance must conform to that. Many schema-processors can only access root-elements directly. I think that for usability and portability the structures.xsd should have that also. I think this is a left-over situation because (I am looking quite some years at OpenEHR), in the past, it was not done to archetype ITEM_STRUCTURE's as root, they did only appear as property. I don't know when the first ITEM_STRUCTURE derived archetypes appeared in CKM. I remember Sam mentioning, some years ago, that he didn't like the demographics-classes, but that they should be replaced by generic structures derived from ITEM_STRUCTURE. I had this discussion with him in the context of the Ocean-archetype editor which is build (maybe partly) by Sam, and also does not support demographics (It is sometime ago I looked for the last time) It is a valid opinion, but this advice was not followed by the community. However, the demographic-specs are valid inside the OpenEHR specs. They also appear in CKM. But still ITEM_STRUCTURE-derived archetypes appeared in CKM, but for other purposes than demographics. There can be XML-instances from ITEM_STRUCTURE-derived. So also for this reason, the XSD should declare ITEM_STRUCTURE derived elements globally. And also besides this all, the globaly defined items, must be meant to be a property of other definitions, because there is no class in the reference model which is called items. Considering that, I think, the items is (originally ) meant of type LOCATABLE to satisfy all possible appearances of the property items in structures, which have a semantically other meaning. But this is not following the granularity of the specs. So the items properties which are in the structures have a more fine-grained definition. Maybe this is corrected, anyway, this how it should be. So I think, the items element it is a left over, an element should be declared globally if it is used in more then one complex type, but it isn't used at all. So it is there doing nothing. That is why I asked about that. - Besides the portability among schema-processors As you can see it in the demographics.xsd which comes from LinkEHR, there is for every concrete class a global element declaration. It has a very precise interface, which makes it easier to develop code against it. That is why it is like that. LinkEHR uses it in code. So, this is the usability-argument. See also this tutorial http://www.herongyang.com/XML-** Schema/Language-Basic-Declare-**Root-Element.htmlhttp://www.herongyang.com/XML-Schema/Language-Basic-Declare-Root-Element.html by Dr. Herong Yang: Rule 1. A schema must have at least one Element Declaration Component to declare a root element for the conforming XML document. That is how it should be, also in my opinion, as I said, for portability to all kind of schema-processing environments. I would like to see the OpenEHR-foundation to take this position too. And if they don't, which can result also in valid XSD, they should at least explain why they don't. There are many styles for schema-organization, and one must make his choice and explain why. --- But even if they don't, I write my own XSD, I can live without the OpenEHR-XSD, but it would be nice to have following my purpose defined XSD from the foundation. Thanks for your reply Bert __**_ openEHR-technical mailing list openEHR-technical at lists.**openehr.orgopenEHR-technical at lists.openehr.org http://lists.openehr.org/**mailman/listinfo/openehr-** technical_lists.openehr.orghttp://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/20121128/157e5882/attachment.html
Questions about the XSD-files.
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 On Nov 27, 2012 8:50 PM, Bert Verhees bert.verhees at rosa.nl wrote: 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) There is no other globally defined element in the structures.xsd, so there is no other root-element. Every valid XML-instance has one (only one) root-element. So, many schema-processors need at least one root-element in the XSD for validation-purpose, and the XML instance must conform to that. Many schema-processors can only access root-elements directly. I think that for usability and portability the structures.xsd should have that also. I think this is a left-over situation because (I am looking quite some years at OpenEHR), in the past, it was not done to archetype ITEM_STRUCTURE's as root, they did only appear as property. I don't know when the first ITEM_STRUCTURE derived archetypes appeared in CKM. I remember Sam mentioning, some years ago, that he didn't like the demographics-classes, but that they should be replaced by generic structures derived from ITEM_STRUCTURE. I had this discussion with him in the context of the Ocean-archetype editor which is build (maybe partly) by Sam, and also does not support demographics (It is sometime ago I looked for the last time) It is a valid opinion, but this advice was not followed by the community. However, the demographic-specs are valid inside the OpenEHR specs. They also appear in CKM. But still ITEM_STRUCTURE-derived archetypes appeared in CKM, but for other purposes than demographics. There can be XML-instances from ITEM_STRUCTURE-derived. So also for this reason, the XSD should declare ITEM_STRUCTURE derived elements globally. And also besides this all, the globaly defined items, must be meant to be a property of other definitions, because there is no class in the reference model which is called items. Considering that, I think, the items is (originally ) meant of type LOCATABLE to satisfy all possible appearances of the property items in structures, which have a semantically other meaning. But this is not following the granularity of the specs. So the items properties which are in the structures have a more fine-grained definition. Maybe this is corrected, anyway, this how it should be. So I think, the items element it is a left over, an element should be declared globally if it is used in more then one complex type, but it isn't used at all. So it is there doing nothing. That is why I asked about that. - Besides the portability among schema-processors As you can see it in the demographics.xsd which comes from LinkEHR, there is for every concrete class a global element declaration. It has a very precise interface, which makes it easier to develop code against it. That is why it is like that. LinkEHR uses it in code. So, this is the usability-argument. See also this tutorial http://www.herongyang.com/XML-** Schema/Language-Basic-Declare-**Root-Element.htmlhttp://www.herongyang.com/XML-Schema/Language-Basic-Declare-Root-Element.html by Dr. Herong Yang: Rule 1. A schema must have at least one Element Declaration Component to declare a root element for the conforming XML document. That is how it should be, also in my opinion, as I said, for portability to all kind of schema-processing environments. I would like to see the OpenEHR-foundation to take this position too. And if they don't, which can result also in valid XSD, they should at least explain why they don't. There are many styles for schema-organization, and one must make his choice and explain why. --- But even if they don't, I write my own XSD, I can live without the OpenEHR-XSD, but it would be nice to have following my purpose defined XSD from the foundation. Thanks for your reply Bert __**_ openEHR-technical mailing list openEHR-technical at lists.**openehr.orgopenEHR-technical at lists.openehr.org http://lists.openehr.org/**mailman/listinfo/openehr-**
Questions about the XSD-files.
thanks, Peter, I will work on it tomorrow. Bert Verstuurd vanaf mijn iPad Op 27 nov. 2012 om 23:06 heeft Peter Gummer peter.gummer at oceaninformatics.com het volgende geschreven: 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 ___ 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.
Verstuurd vanaf mijn iPad Op 27 nov. 2012 om 20:24 heeft Heath Frankel heath.frankel at oceaninformatics.com het volgende geschreven: 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 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 On Nov 27, 2012 8:50 PM, Bert Verhees bert.verhees at rosa.nl wrote: 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) There is no other globally defined element in the structures.xsd, so there is no other root-element. Every valid XML-instance has one (only one) root-element. So, many schema-processors need at least one root-element in the XSD for validation-purpose, and the XML instance must conform to that. Many schema-processors can only access root-elements directly. I think that for usability and portability the structures.xsd should have that also. I think this is a left-over situation because (I am looking quite some years at OpenEHR), in the past, it was not done to archetype ITEM_STRUCTURE's as root, they did only appear as property. I don't know when the first ITEM_STRUCTURE derived archetypes appeared in CKM. I remember Sam mentioning, some years ago, that he didn't like the demographics-classes, but that they should be replaced by generic structures derived from ITEM_STRUCTURE. I had this discussion with him in the context of the Ocean-archetype editor which is build (maybe partly) by Sam, and also does not support demographics (It is sometime ago I looked for the last time) It is a valid opinion, but this advice was not followed by the community. However, the demographic-specs are valid inside the OpenEHR specs. They also appear in CKM. But still ITEM_STRUCTURE-derived archetypes appeared in CKM, but for other purposes than demographics. There can be XML-instances from ITEM_STRUCTURE-derived. So also for this reason, the XSD should declare ITEM_STRUCTURE derived elements globally. And also besides this all, the globaly defined items, must be meant to be a property of other definitions, because there is no class in the reference model which is called items. Considering that, I think, the items is (originally ) meant of type LOCATABLE to satisfy all possible appearances of the property items in structures, which have a semantically other meaning. But this is not following the granularity of the specs. So the items properties which are in the structures have a more fine-grained definition. Maybe this is corrected, anyway, this how it should be. So I think, the items element it is a left over, an element should be declared globally if it is used in more then one complex type, but it isn't used at all. So it is there doing nothing. That is why I asked about that. - Besides the portability among schema-processors As you can see it in the demographics.xsd which comes from LinkEHR, there is for every concrete class a global element declaration. It has a very precise interface, which makes it easier to develop code against it. That is why it is like that. LinkEHR uses it in code. So, this is the usability-argument. See also this tutorial http://www.herongyang.com/XML-Schema/Language-Basic-Declare-Root-Element.html by Dr. Herong Yang: Rule 1. A schema must have at least one Element Declaration Component to declare a root element for the conforming XML document. That is how it should be, also in my opinion, as I said, for portability to all kind of schema-processing environments. I would like to see the OpenEHR-foundation to take this position too. And if they don't, which can result also in valid XSD, they should at least explain why they don't. There are many styles for schema-organization, and one must make his choice and explain why. --- But even if they don't, I write my own XSD, I can live without the OpenEHR-XSD, but it would be nice to have following my purpose defined XSD from the foundation. Thanks for your reply Bert ___ openEHR-technical mailing list openEHR-technical at
Questions about the XSD-files.
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 On Nov 28, 2012 7:42 AM, Seref Arikan serefarikan at kurumsalteknoloji.com wrote: 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? On Tue, Nov 27, 2012 at 7:24 PM, Heath Frankel heath.frankel at oceaninformatics.com wrote: 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 On Nov 27, 2012 8:50 PM, Bert Verhees bert.verhees at rosa.nl wrote: 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) There is no other globally defined element in the structures.xsd, so there is no other root-element. Every valid XML-instance has one (only one) root-element. So, many schema-processors need at least one root-element in the XSD for validation-purpose, and the XML instance must conform to that. Many schema-processors can only access root-elements directly. I think that for usability and portability the structures.xsd should have that also. I think this is a left-over situation because (I am looking quite some years at OpenEHR), in the past, it was not done to archetype ITEM_STRUCTURE's as root, they did only appear as property. I don't know when the first ITEM_STRUCTURE derived archetypes appeared in CKM. I remember Sam mentioning, some years ago, that he didn't like the demographics-classes, but that they should be replaced by generic structures derived from ITEM_STRUCTURE. I had this discussion with him in the context of the Ocean-archetype editor which is build (maybe partly) by Sam, and also does not support demographics (It is sometime ago I looked for the last time) It is a valid opinion, but this advice was not followed by the community. However, the demographic-specs are valid inside the OpenEHR specs. They also appear in CKM. But still ITEM_STRUCTURE-derived archetypes appeared in CKM, but for other purposes than demographics. There can be XML-instances from ITEM_STRUCTURE-derived. So also for this reason, the XSD should declare ITEM_STRUCTURE derived elements globally. And also besides this all, the globaly defined items, must be meant to be a property of other definitions, because there is no class in the reference model which is called items. Considering that, I think, the items is (originally ) meant of type LOCATABLE to satisfy all possible appearances of the property items in structures, which have a semantically other meaning. But this is not following the granularity of the specs. So the items properties which are in the structures have a more fine-grained definition. Maybe this is corrected, anyway, this how it should be. So I think, the items element it is a left over, an element should be declared globally if it is used in more then one complex type, but it isn't used at all. So it is there doing nothing. That is why I asked about that. - Besides the portability among schema-processors As you can see it in the demographics.xsd which comes from LinkEHR, there is for every concrete class a global element declaration. It has a very precise interface, which makes it easier to develop code against it. That is why it is like that. LinkEHR uses it in code. So, this is the usability-argument. See also this tutorial http://www.herongyang.com/XML-**
Questions about the XSD-files.
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: oe:items xs:type=oe:ITEM_TREE xmlns:oe=... xmlns:xs=... archetype_node_id=..oe:items Heath On Nov 28, 2012 9:07 AM, Bert Verhees bert.verhees at rosa.nl wrote: Verstuurd vanaf mijn iPad Op 27 nov. 2012 om 20:24 heeft Heath Frankel heath.frankel at oceaninformatics.com het volgende geschreven: 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 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 On Nov 27, 2012 8:50 PM, Bert Verhees bert.verhees at rosa.nl wrote: 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) There is no other globally defined element in the structures.xsd, so there is no other root-element. Every valid XML-instance has one (only one) root-element. So, many schema-processors need at least one root-element in the XSD for validation-purpose, and the XML instance must conform to that. Many schema-processors can only access root-elements directly. I think that for usability and portability the structures.xsd should have that also. I think this is a left-over situation because (I am looking quite some years at OpenEHR), in the past, it was not done to archetype ITEM_STRUCTURE's as root, they did only appear as property. I don't know when the first ITEM_STRUCTURE derived archetypes appeared in CKM. I remember Sam mentioning, some years ago, that he didn't like the demographics-classes, but that they should be replaced by generic structures derived from ITEM_STRUCTURE. I had this discussion with him in the context of the Ocean-archetype editor which is build (maybe partly) by Sam, and also does not support demographics (It is sometime ago I looked for the last time) It is a valid opinion, but this advice was not followed by the community. However, the demographic-specs are valid inside the OpenEHR specs. They also appear in CKM. But still ITEM_STRUCTURE-derived archetypes appeared in CKM, but for other purposes than demographics. There can be XML-instances from ITEM_STRUCTURE-derived. So also for this reason, the XSD should declare ITEM_STRUCTURE derived elements globally. And also besides this all, the globaly defined items, must be meant to be a property of other definitions, because there is no class in the reference model which is called items. Considering that, I think, the items is (originally ) meant of type LOCATABLE to satisfy all possible appearances of the property items in structures, which have a semantically other meaning. But this is not following the granularity of the specs. So the items properties which are in the structures have a more fine-grained definition. Maybe this is corrected, anyway, this how it should be. So I think, the items element it is a left over, an element should be declared globally if it is used in more then one complex type, but it isn't used at all. So it is there doing nothing. That is why I asked about that. - Besides the portability among schema-processors As you can see it in the demographics.xsd which comes from LinkEHR, there is for every concrete class a global element declaration. It has a very precise interface, which makes it easier to develop code against it. That is why it is like that. LinkEHR uses it in code. So, this is the usability-argument. See also this tutorial http://www.herongyang.com/XML-** Schema/Language-Basic-Declare-**Root-Element.htmlhttp://www.herongyang.com/XML-Schema/Language-Basic-Declare-Root-Element.html by Dr. Herong Yang: Rule 1. A schema must have at least one Element Declaration Component to declare a root element for the conforming XML document. That is how it should be, also in my opinion, as I said, for portability to all kind of schema-processing environments. I would like to see the OpenEHR-foundation to take this position too. And if they don't, which can result also in valid XSD, they should at least explain why they don't. There are many styles
Questions about the XSD-files.
On 11/28/2012 02:35 AM, Heath Frankel wrote: 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. 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 Heath On Nov 28, 2012 7:42 AM, Seref Arikan serefarikan at kurumsalteknoloji.com mailto:serefarikan at kurumsalteknoloji.com wrote: 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? On Tue, Nov 27, 2012 at 7:24 PM, Heath Frankel heath.frankel at oceaninformatics.com mailto:heath.frankel at oceaninformatics.com wrote: 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 On Nov 27, 2012 8:50 PM, Bert Verhees bert.verhees at rosa.nl mailto:bert.verhees at rosa.nl wrote: 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) There is no other globally defined element in the structures.xsd, so there is no other root-element. Every valid XML-instance has one (only one) root-element. So, many schema-processors need at least one root-element in the XSD for validation-purpose, and the XML instance must conform to that. Many schema-processors can only access root-elements directly. I think that for usability and portability the structures.xsd should have that also. I think this is a left-over situation because (I am looking quite some years at OpenEHR), in the past, it was not done to archetype ITEM_STRUCTURE's as root, they did only appear as property. I don't know when the first ITEM_STRUCTURE derived archetypes appeared in CKM. I remember Sam mentioning, some years ago, that he didn't like the demographics-classes, but that they should be replaced by generic structures derived from ITEM_STRUCTURE. I had this discussion with him in the context of the Ocean-archetype editor which is build (maybe partly) by Sam, and also does not support demographics (It is sometime ago I looked for the last time) It is a valid opinion, but this advice was not followed by the community. However, the demographic-specs are valid inside the OpenEHR specs. They also appear in CKM. But still ITEM_STRUCTURE-derived archetypes appeared in CKM, but for other purposes than demographics. There can be XML-instances from ITEM_STRUCTURE-derived. So also for this reason, the XSD should declare ITEM_STRUCTURE derived elements globally. And also besides this all, the globaly defined items, must be meant to be a property of other definitions,
Questions about the XSD-files.
On 11/27/2012 10:42 PM, Seref Arikan wrote: 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? 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. - I just want root-elements for every concrete class which can be root in a XML-instantiation. This is not for DvQuantity, because that class will never be root in an OpenEHR XML instance-document. It is maybe 10 lines added, and none changed or removed. If Heath wants to keep that items line, it is not in my way. And the lines I want added will be in no ones way. It is a recommendation to add these. I can list the quotes of well known XML-specialists which recommend this. But I don't want to spend any more time on this issue, because: - it can easily become offending - it doesn't matter to me, I write my own XSD (better, I have them ready). - I don't mind if the OpenEHR website proceeds in this way, it is not my problem. best regards Bert Verhees
Questions about the XSD-files.
On 11/27/2012 10:42 PM, Seref Arikan wrote: 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? 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. - I just want root-elements for every concrete class which can be root in a XML-instantiation. This is not for DvQuantity, because that class will never be root in an OpenEHR XML instance-document. It is maybe 10 lines added, and none changed or removed. If Heath wants to keep that items line, it is not in my way. And the lines I want added will be in no ones way. It is a recommendation to add these. I can list the quotes of well known XML-specialists which recommend this. But I don't want to spend any more time on this issue, because: - it can easily become offending - it doesn't matter to me, I write my own XSD (better, I have them ready). - I don't mind if the OpenEHR website proceeds in this way, it is not my problem. best regards Bert Verhees
Questions about the XSD-files.
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. On Wed, Nov 28, 2012 at 9:29 AM, Bert Verhees bert.verhees at rosa.nl wrote: On 11/27/2012 10:42 PM, Seref Arikan wrote: 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. [...] It is maybe 10 lines added, and none changed or removed. If Heath wants to keep that items line, it is not in my way. And the lines I want added will be in no ones way. It is a recommendation to add these.
Questions about the XSD-files.
On 11/28/2012 09:46 AM, Erik Sundvall wrote: 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. If so, I want to excuse for that. Bert
Questions about the XSD-files.
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. 2012/11/28 Erik Sundvall erik.sundvall at liu.se: 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. On Wed, Nov 28, 2012 at 9:29 AM, Bert Verhees bert.verhees at rosa.nl wrote: On 11/27/2012 10:42 PM, Seref Arikan wrote: 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. [...] It is maybe 10 lines added, and none changed or removed. If Heath wants to keep that items line, it is not in my way. And the lines I want added will be in no ones way. It is a recommendation to add these. ___ 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.
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 On Nov 28, 2012 5:52 PM, Bert Verhees bert.verhees at rosa.nl wrote: On 11/28/2012 02:35 AM, Heath Frankel wrote: 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. 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 Heath On Nov 28, 2012 7:42 AM, Seref Arikan serefarikan at kurumsalteknoloji.com wrote: 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? On Tue, Nov 27, 2012 at 7:24 PM, Heath Frankel heath.frankel at oceaninformatics.com wrote: 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 On Nov 27, 2012 8:50 PM, Bert Verhees bert.verhees at rosa.nl wrote: 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) There is no other globally defined element in the structures.xsd, so there is no other root-element. Every valid XML-instance has one (only one) root-element. So, many schema-processors need at least one root-element in the XSD for validation-purpose, and the XML instance must conform to that. Many schema-processors can only access root-elements directly. I think that for usability and portability the structures.xsd should have that also. I think this is a left-over situation because (I am looking quite some years at OpenEHR), in the past, it was not done to archetype ITEM_STRUCTURE's as root, they did only appear as property. I don't know when the first ITEM_STRUCTURE derived archetypes appeared in CKM. I remember Sam mentioning, some years ago, that he didn't like the demographics-classes, but that they should be replaced by generic structures derived from ITEM_STRUCTURE. I had this discussion with him in the context of the Ocean-archetype editor which is build (maybe partly) by Sam, and also does not support demographics (It is sometime ago I looked for the last time) It is a valid opinion, but this advice was not followed by the community. However, the demographic-specs are valid inside the OpenEHR specs. They also appear in CKM. But still ITEM_STRUCTURE-derived archetypes appeared in CKM, but for other purposes than demographics. There can be XML-instances from ITEM_STRUCTURE-derived. So also for this reason, the XSD should declare ITEM_STRUCTURE derived elements globally. And also besides this all, the globaly defined items, must be meant to be a property of other definitions, because there is no class in the reference model which is called items. Considering that, I think, the items is (originally ) meant of type LOCATABLE to satisfy all possible appearances of the property items in structures, which have a semantically other meaning. But this is not following the granularity of the specs. So the items properties which are in the structures have a more fine-grained definition. Maybe this is corrected, anyway, this how it should be. So I think, the items
Questions about the XSD-files.
;) Bert On 11/28/2012 12:01 PM, Heath Frankel wrote: 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 On Nov 28, 2012 5:52 PM, Bert Verhees bert.verhees at rosa.nl mailto:bert.verhees at rosa.nl wrote: On 11/28/2012 02:35 AM, Heath Frankel wrote: 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. 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 Heath On Nov 28, 2012 7:42 AM, Seref Arikan serefarikan at kurumsalteknoloji.com mailto:serefarikan at kurumsalteknoloji.com wrote: 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? On Tue, Nov 27, 2012 at 7:24 PM, Heath Frankel heath.frankel at oceaninformatics.com mailto:heath.frankel at oceaninformatics.com wrote: 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 On Nov 27, 2012 8:50 PM, Bert Verhees bert.verhees at rosa.nl mailto:bert.verhees at rosa.nl wrote: 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) There is no other globally defined element in the structures.xsd, so there is no other root-element. Every valid XML-instance has one (only one) root-element. So, many schema-processors need at least one root-element in the XSD for validation-purpose, and the XML instance must conform to that. Many schema-processors can only access root-elements directly. I think that for usability and portability the structures.xsd should have that also. I think this is a left-over situation because (I am looking quite some years at OpenEHR), in the past, it was not done to archetype ITEM_STRUCTURE's as root, they did only appear as property. I don't know when the first ITEM_STRUCTURE derived archetypes appeared in CKM. I remember Sam mentioning, some years ago, that he didn't like the demographics-classes, but that they should be replaced by generic structures derived from ITEM_STRUCTURE. I had this discussion with him in the context of
Questions about the XSD-files.
;) Bert On 11/28/2012 12:01 PM, Heath Frankel wrote: 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 On Nov 28, 2012 5:52 PM, Bert Verhees bert.verhees at rosa.nl mailto:bert.verhees at rosa.nl wrote: On 11/28/2012 02:35 AM, Heath Frankel wrote: 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. 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 Heath On Nov 28, 2012 7:42 AM, Seref Arikan serefarikan at kurumsalteknoloji.com mailto:serefarikan at kurumsalteknoloji.com wrote: 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? On Tue, Nov 27, 2012 at 7:24 PM, Heath Frankel heath.frankel at oceaninformatics.com mailto:heath.frankel at oceaninformatics.com wrote: 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 On Nov 27, 2012 8:50 PM, Bert Verhees bert.verhees at rosa.nl mailto:bert.verhees at rosa.nl wrote: 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) There is no other globally defined element in the structures.xsd, so there is no other root-element. Every valid XML-instance has one (only one) root-element. So, many schema-processors need at least one root-element in the XSD for validation-purpose, and the XML instance must conform to that. Many schema-processors can only access root-elements directly. I think that for usability and portability the structures.xsd should have that also. I think this is a left-over situation because (I am looking quite some years at OpenEHR), in the past, it was not done to archetype ITEM_STRUCTURE's as root, they did only appear as property. I don't know when the first ITEM_STRUCTURE derived archetypes appeared in CKM. I remember Sam mentioning, some years ago, that he didn't like the demographics-classes, but that they should be replaced by generic structures derived from ITEM_STRUCTURE. I had this discussion with him in the context of
Questions about the XSD-files.
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
Questions about the XSD-files.
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
Questions about the XSD-files.
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 -Original Message- From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On Behalf Of Bert Verhees Sent: Tuesday, 27 November 2012 3:07 AM To: For openEHR technical discussions Subject: 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. xs:element name=items type=LOCATABLE/ I commented it out, and it still validates fine. [HKF: ] What did you comment out, the entire element? 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? 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 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. [HKF: ] It was if you used the items element above. 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. 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. [HKF: ] Yeah, I guess that shows the EHR focus of the specs. I also have a schema that could be used, I may have already put it up in Jira. Thanks Bert Verhees ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.or g -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20121127/ac7c080c/attachment.html
Questions about the XSD-files.
Verstuurd vanaf mijn iPad (I leave this notice so people understand the torture I went through, while replying to this email) Op 26 nov. 2012 om 23:58 heeft Heath Frankel heath.frankel at oceaninformatics.com het volgende geschreven: 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. xs:element name=items type=LOCATABLE/ 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 the 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 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20121127/e8d85af7/attachment.html
Questions about the XSD-files.
On 26/11/2012 17:02, 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. 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
Questions about the XSD-files.
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 On Nov 27, 2012 6:19 PM, Bert Verhees bert.verhees at rosa.nl wrote: On 11/27/2012 04:26 AM, Thomas Beale wrote: On 26/11/2012 17:02, 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. 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. 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 __**_ openEHR-technical mailing list openEHR-technical at lists.**openehr.orgopenEHR-technical at lists.openehr.org http://lists.openehr.org/**mailman/listinfo/openehr-** technical_lists.openehr.orghttp://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/28ef877b/attachment.html
Questions about the XSD-files.
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) There is no other globally defined element in the structures.xsd, so there is no other root-element. Every valid XML-instance has one (only one) root-element. So, many schema-processors need at least one root-element in the XSD for validation-purpose, and the XML instance must conform to that. Many schema-processors can only access root-elements directly. I think that for usability and portability the structures.xsd should have that also. I think this is a left-over situation because (I am looking quite some years at OpenEHR), in the past, it was not done to archetype ITEM_STRUCTURE's as root, they did only appear as property. I don't know when the first ITEM_STRUCTURE derived archetypes appeared in CKM. I remember Sam mentioning, some years ago, that he didn't like the demographics-classes, but that they should be replaced by generic structures derived from ITEM_STRUCTURE. I had this discussion with him in the context of the Ocean-archetype editor which is build (maybe partly) by Sam, and also does not support demographics (It is sometime ago I looked for the last time) It is a valid opinion, but this advice was not followed by the community. However, the demographic-specs are valid inside the OpenEHR specs. They also appear in CKM. But still ITEM_STRUCTURE-derived archetypes appeared in CKM, but for other purposes than demographics. There can be XML-instances from ITEM_STRUCTURE-derived. So also for this reason, the XSD should declare ITEM_STRUCTURE derived elements globally. And also besides this all, the globaly defined items, must be meant to be a property of other definitions, because there is no class in the reference model which is called items. Considering that, I think, the items is (originally ) meant of type LOCATABLE to satisfy all possible appearances of the property items in structures, which have a semantically other meaning. But this is not following the granularity of the specs. So the items properties which are in the structures have a more fine-grained definition. Maybe this is corrected, anyway, this how it should be. So I think, the items element it is a left over, an element should be declared globally if it is used in more then one complex type, but it isn't used at all. So it is there doing nothing. That is why I asked about that. - Besides the portability among schema-processors As you can see it in the demographics.xsd which comes from LinkEHR, there is for every concrete class a global element declaration. It has a very precise interface, which makes it easier to develop code against it. That is why it is like that. LinkEHR uses it in code. So, this is the usability-argument. See also this tutorial http://www.herongyang.com/XML-Schema/Language-Basic-Declare-Root-Element.html by Dr. Herong Yang: Rule 1. A schema must have at least one Element Declaration Component to declare a root element for the conforming XML document. That is how it should be, also in my opinion, as I said, for portability to all kind of schema-processing environments. I would like to see the OpenEHR-foundation to take this position too. And if they don't, which can result also in valid XSD, they should at least explain why they don't. There are many styles for schema-organization, and one must make his choice and explain why. --- But even if they don't, I write my own XSD, I can live without the OpenEHR-XSD, but it would be nice to have following my purpose defined XSD from the foundation. Thanks for your reply Bert
Questions about the XSD-files.
Verstuurd vanaf mijn iPad Op 27 nov. 2012 om 20:13 heeft Heath Frankel heath.frankel at oceaninformatics.com het volgende geschreven: 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 Heath On Nov 27, 2012 8:50 PM, Bert Verhees bert.verhees at rosa.nl wrote: 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) There is no other globally defined element in the structures.xsd, so there is no other root-element. Every valid XML-instance has one (only one) root-element. So, many schema-processors need at least one root-element in the XSD for validation-purpose, and the XML instance must conform to that. Many schema-processors can only access root-elements directly. I think that for usability and portability the structures.xsd should have that also. I think this is a left-over situation because (I am looking quite some years at OpenEHR), in the past, it was not done to archetype ITEM_STRUCTURE's as root, they did only appear as property. I don't know when the first ITEM_STRUCTURE derived archetypes appeared in CKM. I remember Sam mentioning, some years ago, that he didn't like the demographics-classes, but that they should be replaced by generic structures derived from ITEM_STRUCTURE. I had this discussion with him in the context of the Ocean-archetype editor which is build (maybe partly) by Sam, and also does not support demographics (It is sometime ago I looked for the last time) It is a valid opinion, but this advice was not followed by the community. However, the demographic-specs are valid inside the OpenEHR specs. They also appear in CKM. But still ITEM_STRUCTURE-derived archetypes appeared in CKM, but for other purposes than demographics. There can be XML-instances from ITEM_STRUCTURE-derived. So also for this reason, the XSD should declare ITEM_STRUCTURE derived elements globally. And also besides this all, the globaly defined items, must be meant to be a property of other definitions, because there is no class in the reference model which is called items. Considering that, I think, the items is (originally ) meant of type LOCATABLE to satisfy all possible appearances of the property items in structures, which have a semantically other meaning. But this is not following the granularity of the specs. So the items properties which are in the structures have a more fine-grained definition. Maybe this is corrected, anyway, this how it should be. So I think, the items element it is a left over, an element should be declared globally if it is used in more then one complex type, but it isn't used at all. So it is there doing nothing. That is why I asked about that. - Besides the portability among schema-processors As you can see it in the demographics.xsd which comes from LinkEHR, there is for every concrete class a global element declaration. It has a very precise interface, which makes it easier to develop code against it. That is why it is like that. LinkEHR uses it in code. So, this is the usability-argument. See also this tutorial http://www.herongyang.com/XML-Schema/Language-Basic-Declare-Root-Element.html by Dr. Herong Yang: Rule 1. A schema must have at least one Element Declaration Component to declare a root element for the conforming XML document. That is how it should be, also in my opinion, as I said, for portability to all kind of schema-processing environments. I would like to see the OpenEHR-foundation to take this position too. And if they don't, which can result also in valid XSD, they should at least explain why they don't. There are many styles for schema-organization, and one must make his choice and explain why. --- But even if they don't, I write my own XSD, I can live without the OpenEHR-XSD, but it would be nice to have following my purpose defined XSD from the foundation. Thanks for your reply Bert ___ 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:
Questions about the XSD-files.
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. Verstuurd vanaf mijn iPad Op 27 nov. 2012 om 20:24 heeft Heath Frankel heath.frankel at oceaninformatics.com het volgende geschreven: I am still not understanding you issues with this element other than styling. If you have any technical issue please raise a jira issue
Questions about the XSD-files.
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? On Tue, Nov 27, 2012 at 7:24 PM, Heath Frankel heath.frankel at oceaninformatics.com wrote: 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 On Nov 27, 2012 8:50 PM, Bert Verhees bert.verhees at rosa.nl wrote: 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) There is no other globally defined element in the structures.xsd, so there is no other root-element. Every valid XML-instance has one (only one) root-element. So, many schema-processors need at least one root-element in the XSD for validation-purpose, and the XML instance must conform to that. Many schema-processors can only access root-elements directly. I think that for usability and portability the structures.xsd should have that also. I think this is a left-over situation because (I am looking quite some years at OpenEHR), in the past, it was not done to archetype ITEM_STRUCTURE's as root, they did only appear as property. I don't know when the first ITEM_STRUCTURE derived archetypes appeared in CKM. I remember Sam mentioning, some years ago, that he didn't like the demographics-classes, but that they should be replaced by generic structures derived from ITEM_STRUCTURE. I had this discussion with him in the context of the Ocean-archetype editor which is build (maybe partly) by Sam, and also does not support demographics (It is sometime ago I looked for the last time) It is a valid opinion, but this advice was not followed by the community. However, the demographic-specs are valid inside the OpenEHR specs. They also appear in CKM. But still ITEM_STRUCTURE-derived archetypes appeared in CKM, but for other purposes than demographics. There can be XML-instances from ITEM_STRUCTURE-derived. So also for this reason, the XSD should declare ITEM_STRUCTURE derived elements globally. And also besides this all, the globaly defined items, must be meant to be a property of other definitions, because there is no class in the reference model which is called items. Considering that, I think, the items is (originally ) meant of type LOCATABLE to satisfy all possible appearances of the property items in structures, which have a semantically other meaning. But this is not following the granularity of the specs. So the items properties which are in the structures have a more fine-grained definition. Maybe this is corrected, anyway, this how it should be. So I think, the items element it is a left over, an element should be declared globally if it is used in more then one complex type, but it isn't used at all. So it is there doing nothing. That is why I asked about that. - Besides the portability among schema-processors As you can see it in the demographics.xsd which comes from LinkEHR, there is for every concrete class a global element declaration. It has a very precise interface, which makes it easier to develop code against it. That is why it is like that. LinkEHR uses it in code. So, this is the usability-argument. See also this tutorial http://www.herongyang.com/XML-** Schema/Language-Basic-Declare-**Root-Element.htmlhttp://www.herongyang.com/XML-Schema/Language-Basic-Declare-Root-Element.html by Dr. Herong Yang: Rule 1. A schema must have at least one Element Declaration Component to declare a root element for the conforming XML document. That is how it should be, also in my opinion, as I said, for portability to all kind of schema-processing
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. 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
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 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
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. 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
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 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
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 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.xsdhttp://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.orgopenEHR-technical at lists.openehr.org http://lists.openehr.org/**mailman/listinfo/openehr-** technical_lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org __**_ openEHR-technical mailing list openEHR-technical at lists.**openehr.orgopenEHR-technical at lists.openehr.org http://lists.openehr.org/**mailman/listinfo/openehr-** technical_lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org __**_ openEHR-technical mailing list openEHR-technical at lists.**openehr.orgopenEHR-technical at lists.openehr.org http://lists.openehr.org/**mailman/listinfo/openehr-** technical_lists.openehr.orghttp://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.
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
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 bert.verhees at rosa.nlwrote: 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.xsdhttp://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.orgopenEHR-technical at lists.openehr.org http://lists.openehr.org/**mailman/listinfo/openehr-** technical_lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org __**_ openEHR-technical mailing list openEHR-technical at lists.**openehr.orgopenEHR-technical at lists.openehr.org http://lists.openehr.org/**mailman/listinfo/openehr-** technical_lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org __**_ openEHR-technical mailing list openEHR-technical at lists.**openehr.orgopenEHR-technical at lists.openehr.org http://lists.openehr.org/**mailman/listinfo/openehr-** technical_lists.openehr.orghttp://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.
I think I misunderstood the original question. Thanks for all the responses everyone. Best regards Seref On Mon, Nov 26, 2012 at 8:16 PM, Timothy Cook timothywayne.cook at gmail.comwrote: 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 bert.verhees at rosa.nlwrote: 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.xsdhttp://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.orgopenEHR-technical at lists.openehr.org http://lists.openehr.org/**mailman/listinfo/openehr-** technical_lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org __**_ openEHR-technical mailing list openEHR-technical at lists.**openehr.orgopenEHR-technical at lists.openehr.org http://lists.openehr.org/**mailman/listinfo/openehr-** technical_lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org __**_ openEHR-technical mailing list openEHR-technical at lists.**openehr.orgopenEHR-technical at lists.openehr.org http://lists.openehr.org/**mailman/listinfo/openehr-** technical_lists.openehr.orghttp://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 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 sam.heard at oceaninformatics.com 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 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 ___ 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
