;) Bert
On 11/28/2012 12:01 PM, Heath Frankel wrote: > > Bert, > I too was sharing my knowledge, as one of the authors of the schema > whether they are classed as good or bad, I thought it was worth the > effort explaining the design rationale. > I apologise for wasting your time and will choose more wisely in > future where I spend mine. > Heath > > On Nov 28, 2012 5:52 PM, "Bert Verhees" <bert.verhees at rosa.nl > <mailto:bert.verhees at rosa.nl>> wrote: > > 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 <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/b8c3e8ff/attachment-0001.html>
