all these criticisms are fair, and need to be addressed. I am hoping that we can get some combined effort from various vendors and others to work on a more coherent new generation of tools. The tool space is changing a lot, and it may be that the strategy is to target Eclipse with a group of plug-ins that together provide a good quality integrated modelling experience. I don’t believe this is that hard to achieve - most of the difficult algorithms have been worked out in existing tools, so a fair bit of logic can be ported or re-used. Expect some announcements on this in the near future, and be prepared to contribute!
Would be good to try to reach some collaboration. The new Eclipse 4.2 is really a good platform. As you can see what LinkEHR achieved with a previous 3.x version, and also other examples.
One could also think about editors, and also archetype-editors, a platform in which several OpenEHR tools are combined. When time comes, we should maybe assign tasks to volunteers.
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.
actually this is not true to date; I happen to be in communication with some of the relevant OMG people, and XMI has been recognised as a ‘historically serious problem’ by OMG at a recent board meeting, and is being treated as almost an emergency situation. This was because many tools did not respect the spec, made implementation choices where the spec was lacking, possibly as well as adding things of their own. My impression is that now, i.e. 2013 going forward, things should improve reasonably rapidly. But prior to now, XMI has been a nearly unusable format for practical purposes.
I didn’t know that, what you say about XMI, too bad that it happened. The idea for that kind of standard is good.
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.
You mean EA I presume? I think the next step is to see if we can replicate the EA plug-in in other UML tools. BOUML for example runs on all 3 major platforms, and Rational Software Architect must as well, since it’s Eclipse based. So this is just a piece of work for someone to do. I am sure Michael will publish his plug-in for use by others.
No, no, BOUML has a plugin interface, I accidentally saw on their website, but I read again, it is a plug-out-interface 
I don’t know what the word means.
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.
it’s what we did so far, because at the point when we needed a solution, there simply was nothing working that we could just use. For a future plan… there isn’t a defined plan yet, I think it is up to people here to help define it. The two things I think are important are a) that the semantics of the BMM schemas can be supported by other solutions and tools and b) that a schema file is human readable and writable. We might be able to migrate to using some Ecore syntax, and/or XMI. I personally have not had the time to go and look at this.
One thing the BMM format has achieved which we could not in any other way has been to connect the following tools together:
- at least one UML tool (so far: EA)
- the ADL 1.5 Workbench
- the LinkEHR tool
- tools that Intermountain health are developing to produce archetypes from Intermountain / GE Clinical Element Models
If we replace this connectivity by another method, as long as it works, let’s do it. It’s just a question of determining a coherent strategy together.
Maybe just forget my criticism, I don’t have really good reasons against BMM, I just have a natural aversion against new formats.
Especially if the tooling is expensive and does not run out of the box on my favorite platform.
For EA I need to install Codeweavers to get it to run, I once did something like that, it was a drama.
First by Codeweavers, then buy EA, then spend a day on tweaking, and maybe I get it to run with only a few crashes.
Then there is an update somewhere, and instead of having a day of planned productivity, again a day tweaking…
And there is always that old joke, I don’t know if you know it, people complain I often tell the same jokes.
A, sighing: there are 7 standards for UML exchange.
B, optimistic: I create a standard which makes the other ones obsolete.
A, sighing: there are 8 standards for UML exchange.
B, optimistic: I create a standard which makes the other ones obsolete.
A, sighing: there are 9 standards for UML exchange.
But if on good reasons will be decided to switch to BMM, I take the giant leap. No problem. That kind of leaps is how I make my money.
Bert