Imagine combining all of this with GDL (http://www.openehr.org/releases/CDS/latest/docs/GDL/GDL.html) and a specialised version of a similar DSL to describe archetype / template aware GUIs.
From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On Behalf Of Thomas Beale Sent: 01 March 2017 09:15 To: openehr-technical@lists.openehr.org Subject: Re: inheritance of archetypes On 01/03/2017 09:03, Bert Verhees wrote: Dear all of the technical mailing list, I made a new message tothis list (specialized ;-), so it will be discussed separately. I do that because in the other message, I describe a real problem which needs a solution, and this message is about thinking about a solution in the archetype-framework, which will takes for years to come (if it will come, maybe I am wrong in my proposal). --------------------- When talking about specializing. Specializing an archetype is nothing more then copying an archetype and add/change some constraints in them. Only in older ADL 1.4 tools. In ADL2, specialisation is fully defined<http://www.openehr.org/releases/AM/latest/docs/ADL2/ADL2.html#_specialisation> and implemented in the ADL Workbench, and more recently in the ADL-designer project<https://github.com/openEHR/adl-designer>. it works just like an OO programming language. There are dozens of examples in the test archteypes<https://github.com/openEHR/adl-archetypes/tree/master/ADL2-reference/features>, and also in the CKM archetypes, which when they are read into ADL Workbench, are re-engineered into differential form. This has been the case for over 5 years, with the implementation in ADL Workbench being available for around 4. (You can see the revision history<http://www.openehr.org/releases/AM/latest/docs/ADL2/ADL2.html#_amendment_record> of the AOM2 spec). Using this technology is just a case of moving to ADL/AOM2. - thomas How different is that in programming languages, where the parent-classes are read to understand the child class. There is no need to process all the sourcecode of the child-classes to adapt the changes in a parent class. This is regarded as a big advantage for Object Oriented Programming. Easier to maintain code (and one definitely need a test framework). Imagine that dreaded generic labtest archetype in the other message, I wrote today. How convenient would maintainability become if specializations where really and life-inherited from parent archetypes? Would we need a big part of the LOINC-database of specialized labtest archetypes then, or would we just need to change the identifier and add the appropriate terminology binding? Maybe we could, in case of lab-test, just created the child archetypes only in memory and on the fly, needing only a few keywords to describe the changes. We could take a look at hibernate for Java (or many other ORM-frameworks). They do not deliver the classes needed for handling specific databases, they offer a framework to create/generate those classes. One could argue that specializations are not always inherited like classes in programming languages. That is true. What I suggest here maybe limited to the cases where it is real inheritance. Best regards Bert Verhees
_______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
