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
