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> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20121128/efd29717/attachment.html>
