Steven Kelly on DSM

Three years ago I posted about the lack of adoption and lack of tool interoperability for XMI:

The OMG has XMI versions 1.0, 1.1, 1.2 and 2.0, with 2.1 under development. Looking on Google, I note that there are 865 XMI files on the web using 1.0, 78 for 1.1, 64 for 1.2, and 34 for 2.0 (released in 2003). That gives some indication of the adoption of XMI as a format, and tallies with my own impression. Everybody was interested when it first came out, but most who actually tried to use it found it lacking. One can always hope the situation improves with newer versions...

So have things improved? In a word, no. Google finds 40 files for 2.1 (released in 2005), and the figures for 1.0 have dropped by over 90%. Now even the most used version, 1.2 from over five years ago, only has 136 files, and the figures decline from there. Yet still people I meet believe that XMI is a useful standard that will solve their problems.

What about tool interoperability then? In an article from the MODELS conference, Lundell et al. tested XMI with 14 UML tools. Obviously, the older tools can't load from the newer tools, but can the newer tools read models from the older tools? That's the important question after all, if you want to use XMI as insurance against your tool being discontinued: will this year's tools load last year's models? Here's the table, see the article for full details:

Looking at the tools supporting the latest version, 2.1, the picture looks darker still. None of these tools were able to import even 2.0. If XMI were really being implemented by these tools to offer interoperability and insurance, why would they drop support for the previous version? That leaves you rather open to claims that the intention is to pretend there is a standard, and then spread FUD by claiming that other tools don't support it. If the only tools that can interoperate are jointly developing the same code base (Eclipse, IBM, Borland), it's hardly impressive if their parallel versions work well together.

In the DSM world, of course, all this is somewhat academic: the tests were of the simplest possible UML Class Diagrams. None of the tools support working with DSM languages from another tool. If you want to move your DSM models from one tool to another, the main cost is the same as the cost of building support for that DSM language in the new tool -- translating the models is easy in comparison. In that area I'd say MetaEdit+ wins hands down: nothing comes close in terms of ease and speed for the metamodeler or features provided automatically for the modeler. But don't listen to me -- listen to our customers, industry gurus and even competitors all saying the same thing.

I just got the following interesting feedback from Siemens' Gan Deng on my earlier XMI entry:

I am asking whether you have any idea what MDD tools currently support XMI 2.0 spec? After a thorough search, I found only 2 tools, i.e, EMF and Coral (which only works under Linux). Do you know whether there are any other tools that support it?

Another question, I had a very hard time when I tried to import/export XMI files between various MDD tools although they all claim they support some version of XMI. I could NOT succeed even once! Do you have any idea which exact 2 tools are actually interoperable with each other?

That says it all: the whole point of XMI is interoperability, but there is no pair of tools between which it works. Version 2.0 has been out since 2003, and yet only 2 tools could be found that even claim to support it. That's a pretty strong indictment of the XMI standard itself, but also of the claim that UML is a standard: the fact is that each vendor (and even each user) interprets the spec in their own way. Part of the fault may be in the users and vendors, but if you've ever read the spec it's clear where the majority of the blame lies: not in the individuals who made the spec, but in the whole idea that there could be one modeling language that would be good for everyone. To be useful to everyone, it would have to be so big that it could no longer be good or effective for anyone.

Just got some nice feedback on MetaEdit+ from someone trying it at SAP. He also asked about importing XMI into MetaEdit+. It's hard to give a single correct answer to that, because the variety of XMI formats is considerable.

The OMG has XMI versions 1.0, 1.1, 1.2 and 2.0, with 2.1 under development. Looking on Google, I note that there are 865 XMI files on the web using 1.0, 78 for 1.1, 64 for 1.2, and 34 for 2.0 (released in 2003). That gives some indication of the adoption of XMI as a format, and tallies with my own impression. Everybody was interested when it first came out, but most who actually tried to use it found it lacking. One can always hope the situation improves with newer versions...

XMI suffers from the same problems as MOF, e.g. no support for n-ary relationships and too much dependence on UML. For those reasons it was not sufficiently powerful or flexible for use as the XML import/export format for MetaEdit+. Instead, we used GXL from Andreas Winter and Andy Schürr (among others). GXL is significantly better than XMI in both architecture and schema details, and is supported by an impressive array of tools. As MetaEdit+ 4.0 added the concept of Port, which is not present in GXL, we now use our own extension of GXL.

At the end of the day, though, all XMI and GXL versions are simply XML documents containing sufficient information describing models. As such, there are two ways to get data from XMI into MetaEdit+. One way is by transforming the XMI file into the MetaEdit+ GXL format, e.g. using XSLT. The other way is to have a program read the XMI file and make calls into MetaEdit+ to create corresponding objects etc. The MetaEdit+ API uses SOAP as its protocol, and so can be easily called from pretty much any client. [Some other examples of API and XML import/export use can be found here - with pretty animated GIFs :-).]

In either case, I'd imagine this would be a one-shot transformation: trying to maintain the same models or metamodels in two tools is almost always a bad idea. As someone wise has said "One tool is useful; two tools are a nightmare".