Sorry for moving away from the original subject. It was old annoyance coming up when thinking about some RM issues.
Maybe when having a strict separation between the common and some other parts the problems I mentioned partly disappear. Anyway, it is not yet the moment to discuss such details in the first announcement of a good plan. Best regards Bert Op za 17 feb. 2018 22:53 schreef A Verhees <[email protected]>: > 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
