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-** >>> 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/9e4498ec/attachment.html>
