CLUSTER for one. The XML ITS of the RM is not a pure representation of the RM. Design decisions needed to be made, this is one of them. If you have a problem with it raise a jira issue. Heath On Nov 28, 2012 5:55 AM, "Bert Verhees" <bert.verhees at rosa.nl> wrote:
> > > Verstuurd vanaf mijn iPad > > Op 27 nov. 2012 om 20:13 heeft Heath Frankel < > heath.frankel at oceaninformatics.com> het volgende geschreven: > > Bert, > Items is not a class, it is an attribute. > > > exactly my idea, it is not an attribute in XSD context, but in class > context. > > from which class is it an attribute? > > Bert > > 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/23a24c37/attachment.html>
