> Hi Bert, > > we're not in the business of endorsing UML products, but the UML > situation is always murky. In theory anyone should be able to share > models saved in XMI format. Historically that never worked - each > tool's XMI was broken in different ways, the XMI specification itself > is unclear and vastly over-complicated (as is the underlying > meta-model for UML). > > So let's say the openEHR community would like some proper computable > UML models... what do we do? The most recent attempt was done in a > tool called BOUML <http://bouml.fr/>, which was free and is now a > pay-for tool (about EUR50). It output generation of XMI and code is > superior from what I can work out and it has good support. So I took > the work of Eric Browne who built most of the RM in that tool, > finished it (more or less) and you can see the XMI files online in the > GitHub reference-models repository > <https://github.com/openEHR/reference-models/tree/master/models/openEHR/Release-1.0.2/UML>. > > This XMI file was used as the original input to EA, which more people > seem to use, in CIMI, and it nearly worked. There were some errors, > and the BOUML vendors fixed that very quickly. EA's XMI import was the > main problem however, but to their credit, Sparx also made fixes to > improve it in the last 12 months. > > I think the Rational tool was also able to import this XMI. So it > appears that we are getting closer to XMI becoming a trustworthy > format, and if we continue to publish an XMI file from a reliable > tool, and put pressure on vendors whose XMI doesn't work (along with > everyone else in the world who is in a similar situation), the various > tools should eventually converge on being able to talk the same XMI. > > I think that's about the best we can do. Do you have other suggestions?
Let me explain my problems and what I wish and what I think about doing about that, and than what my problem is with the BMM-solution --------- I have a problem with both archetype-editors, I explained a few times on this list why. Both change archetypes while loading them, f.e. one likes to add node-id's to datavalues, and the other does not like that. There are some more incompatibilities, between the both. I forgot the details. Then one is not able to create demographic archetypes, also a problem. --------- Both are not configurable. I would like to have an archetype editor which can be feeded with some RM-definition, and configured to use it, and then is being able to create archetypes following that definition. --------- That does not exist, I like to build it myself, (when I have time). It is not very difficult, there is already code which can be used for understanding, from LiU, so half of the wheel is already invented. I think I need three months to do so. So I want to to build any RM depending on the feed-file. I would, like LinkEHR, build in in Java, in a eclipse-framework is easy. The archetype-editor should export to ADL, but also export to an XML-schema language, probably Relax NG. --------- Until now LinkEHR used XML-Schema, which is good enough for expressing an master-RM. I am satisfied with any other way too, XMI, for example. I know there is a lot of bad XMI-software, this is because vendors try to put all kind of things in it, which should not be in it, and in this way they make it incompatible. But XMI itself, it is a well defined standard from OMG. It is also a very succesful standard. I think it must be possible to validate and use it in a standardized way. I never studied the software-vendors well, but I think there must be good XMI-producing software. You mention BOUML, I know the product, it has a plugin-interface, at least i --------- My problem is, when you are going to use software which can only run from Windows and you need to create parsers to understand the output (like LinkEHR has published a grammar-file), it will be a stony road, with hard to solve bugs and incompatibility situations. We have seen that until now, only two archetype-editors on the market, and after five years, still not compatible. As I understand you are planning to use a niche definition, which can only be created by one vendor (Enterprise Architect) and let important software (archetype-editors) rely on that. Does not seem wise to me. It would be a big improvement if the BMM-files were in XML, even (but not directly necessary) with a schema to validate them. Then anyone can created them, and it is easy to build tooling, a Reference Model editor, next to an archetype editor. --------- Do you know how I create archetypes (I don't if I can someone else having to do it :), but I work my way in LinkEHR or the Ocean editor, and edit them manually in a text-editor, with syntax-highlighting. Bert -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130501/4c97e5e3/attachment-0001.html>
