On 02/05/2013 08:36, David Moner wrote: > Hi, > > > > Exactly, that was one of the original ideas, at least add that RM > version information at the archetype header. As you say, that only > indicates the version used to create the archetype and not the > compatibility with other versions of the RM (forward or backward). > That could be even added also as metadata: rm_compatibility = > <"openEHR-RM_1.0.0", "openEHR-RM_1.0.1"> > Since we can have all the RM versions loaded at the tools it should be > quite easy to check the validity towards all of them automatically.
I would suggest we don't include this list in the archetypes themselves, because it can easily change as more testing is done - and that would mean reversioning and releasing archetypes as this happens - even though nothing has changed in the archetype. So I would suggest we need to conceive of some functions in a registry service that provides this information. > > > > For me those visualization characteristics are more about preferences > of each tool/user. So it's fine for me to separate them in a different > place, where they can be modified without changing the model itself, > whose definition should remain immutable. maybe 'tool preferences' is the way to go.. > > That, said, I must say that we are not big fans of BMM :-) > While we agree that current alternatives (i.e XMI) are not usable in > practice nowadays, we find extremely improbable that BMM gains big > acceptance outside the openEHR world. I doubt that we ever see the HL7 > CDA model expressed in BMM for example. So we decided to support it as > another option, but we still hope that the industry finds a way to > agree on a common usable format for defining models. > well, as I said earlier, I built it over a weekend because none of the current options were palatable. I still don't see a clear better solution than BMM to our current model interop needs - today. My feeling is that something may emerge out of Ecore that can be usable. Right now, I am not sure still that it is semantically powerful enough. - thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130502/9b9427cd/attachment.html>
