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
