I know Thomas, but they have dependencies to other classes in the RM. To data types, to support. By the way, I have never seen use for translation details except for the archetype metadata. But maybe i missed it. That is possible, if so, excuse me for this example.
The terminology service also has dependencies to rm data types, only because of codephrase. Wouldn't it be possible to avoid that? This also creates a circular dependency at construction of several RM classes. They need the OpenEhr terminology when constructed, and the terminology needs the RM codephrase. The archetype_Id is inherited from object_id, but why is that necessary? What is the advantage? Of course it is not only design, it is also the developers, they create those large libraries, but they are inspired by the theoretical architecture-plan, and maybe they need to do that to avoid circular library references. There is, in my opinion a need to split the RM. Rongs did that a few years ago, he had an Ehr-RM and a (was it...) common RM. A step in a good direction. So splitting up the RM instead of making it larger would be my idea. The first is not easy to do, but the second is, and helps us avoiding further problems and avoiding creating unnecessary large libraries. Bert Op 17 feb. 2018 22:12 schreef "Thomas Beale" <[email protected]>: On 17/02/2018 18:06, A Verhees wrote: If it was to me to design, I would not change the RM. In fact, I think the RM has already classes which do not belong there in my opinion. I think of AuthoredResources, TranslationDetails, they belong in the AOM. these things are generic and are in the Resource specification, in the BASE component <https://www.openehr.org/releases/BASE/latest/docs/resource/resource.html>, allowing them to be re-used where needed. (They were in the AOM but are needed outside of there). - thomas _______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_ lists.openehr.org
_______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
