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> 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> > 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 >>>> 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 >>>> >>>> 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 >> > > > _______________________________________________ > openEHR-technical mailing listopenEHR-technical at > lists.openehr.orghttp://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/bed382fb/attachment-0001.html>
