Cook: There is no need for specialisation or redefinition in MLHIM. Concept Constraint Definitions (CCDS) are immutable once published. In conjunction with their included Reference Model version they endure in order to remain as the model for that instance data. Unlike you, I believe that the ability to read and validate XML data will be around for a looooong time to come. There is simply too much of it for it to go away anytime soon. When it does go away, there will ways to translate it to whatever comes next. Such as there is today.
Beale: I don't disagree with that obviously. All openEHR systems I am aware of process XML data routinely, including HL7v2 data, and CDAs. Beale: But if you say there is no need for specialisation or redefinition it means there is no re-use to speak of - every model is its own thing. This is a major departure from the archetype approach, which is founded upon model reuse and adaptation. And that is the issue, and what is at the root of this dispute. Tim does not see the point of specialization or redefinition, which, in my opinion, is why he can hold forth so strongly for XML. Randy Neall On Fri, Apr 5, 2013 at 6:00 PM, Thomas Beale < thomas.beale at oceaninformatics.com> wrote: > On 05/04/2013 13:03, Thomas Beale wrote: > > > [original post by Tim bounced; reposting manually for him] > > On Thu, Apr 4, 2013 at 12:50 PM, Thomas Beale<thomas.beale at > oceaninformatics.com> <thomas.beale at oceaninformatics.com> wrote: > > > if you mean the competing inheritance models - I have yet to meet any XML > specialist who thinks they work. The maths are against it. > > > Interesting that you, the creator of a technology that makes many > people very uncomfortable (multi-level modelling), thinks that > conventional users of XML have something to say regarding XML as a > multi-level implementation. Confusing. > > > not sure what you want to say here! > > > > Can you point to some MLHIM models that show specialisation, redefinition, > clarity of expression, that sort of thing? I tried to find some but ran into > raw XML source. > > There is no need for specialisation or redefinition in MLHIM. Concept > Constraint Definitions (CCDS) are immutable once published. In > conjunction with their included Reference Model version they endure in > order to remain as the model for that instance data. Unlike you, I > believe that the ability to read and validate XML data will be around > for a looooong time to come. There is simply too much of it for it to > go away anytime soon. When it does go away, there will ways to > translate it to whatever comes next. Such as there is today. > > > I don't disagree with that obviously. All openEHR systems I am aware of > process XML data routinely, including HL7v2 data, and CDAs. > > But if you say there is no need for specialisation or redefinition it > means there is no re-use to speak of - every model is its own thing. This > is a major departure from the archetype approach, which is founded upon > model reuse and adaptation. > > so does openEHR, that's what namespaces are about. If two groups both define > a 'blood pressure' archetype today, there is an immediate problem. In the > future with namespaced ids, the problem becomes manageable, since both forms > can co-exist. > > > Thanks for confirming this problem, for today. I hope that people > realize the potential issues that they are creating by operating > outside of the eco-system. I also hope that whenever, 'the future', > arrives that people will understand that the need to use this > namespace capability. Are there estimates yet as to when the future > will arrive? > > > > Now more or less. New versions of the documents are being published > imminently, and the tooling is catching up to namespaces (also other things > like annotations). > > - thomas > > > _______________________________________________ > 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/20130405/34f41dba/attachment.html>
