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.html<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<openEHR-technical at >> lists.openehr.org> >> http://lists.openehr.org/**mailman/listinfo/openehr-** >> technical_lists.openehr.org<http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org> >> > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > > _______________________________________________ > 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/20121128/7892e8c4/attachment-0001.html>
