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, > 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 > <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/20121128/e7be0f5d/attachment.html>
