> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130502/095727de/attachment.html>
