The mess called XMI (XML Metadata Interchange)
Hello,
XMI is a (in fact it’s not, but that is actually the mess) standard defined by the OMG for the exchange of models between tools.
Steven Kelly of MetaCase has written a blog posting concerning XMI. Basically, he claims that XMI is mostly unusable and its popularity is declining according to google.
The major causes for this unfortunate state of XMI are:
- The OMG hugely over engineered the XMI standard. The XMI specification is based on the MOF and thus introduced an additional level of abstraction.
- The OMG specified a couple of different versions, each requiring its own processing. The different version where driven by the associated UML versions.
- The OMG failed in providing a compliance test suite for XMI. Although they had plans to do this these plans where never realized.
- The vendors are also sometimes accused to actively try to “lock in” their customers to their own tool by making the XMI export proprietary. But on the other side this means that they cannot read XMI files from other tools thus losing possible customers. Personally I think that most vendors did not actively try to make their XMI format proprietary but that they just misinterpreted the XMI specification or that they did not want to spend the required effort to provide a fully compliant XMI format.
In practice, this means that a tool that wants to properly import XMI must write a dedicated importer for each supported other tool and for at least one of the XMI versions that are supported by the other tool.
In addition of being massively incompatible, the XMI files in itself are also often really freaky.
Lets look at an example in MagicDraw. Suppose we want to specify the type of an attribute as Boolean. The UML supports this as a builtin primitive type and thus one could assume that the representation in XMI should be straight forward. Not so with MagicDraw. If you open the dialog for the attribute type and click in the “type” field you are presented with the preselection “$OCL_boolean” and you could be tempted to use this suggestions, especially when you want to use the OCL:
If you resist this temptation and start to type “boo” MagicDraw offers these choices:
While the second choice is probably the better one, as a tool vendor you would have to support both forms since certainly some users would choose the first form.
Now let’s look how these different forms are represented in the XMI.
$OCL_Boolean:
<ownedAttribute xmi:type='uml:Property' xmi:id='_15_0_1_275013a_1210362988887_907256_342' name='underAge' visibility='public'> <type xmi:type='uml:PrimitiveType' href='UML_Standard_Profile.xml#_12_0EAPbeta_f720368_1161801304327_563815_114> <xmi:Extension extender='MagicDraw UML 15.0' extenderID='MagicDraw UML 15.0> <referenceExtension referentPath='UML Standard Profile::Validation Profile::OCL Library::$OCL_Boolean' referentType='PrimitiveType'/> </xmi:Extension> </type> </ownedAttribute>
boolean from the MagicDraw profile:
<ownedAttribute xmi:type='uml:Property' xmi:id='_15_0_1_275013a_1210362988887_907256_342' name='underAge' visibility='public'> <type xmi:type='uml:DataType' href='UML_Standard_Profile.xml#eee_1045467100323_191782_59'> <xmi:Extension extender='MagicDraw UML 15.0' extenderID='MagicDraw UML 15.0'> <referenceExtension referentPath='UML Standard Profile::MagicDraw Profile::datatypes::boolean' referentType='DataType'/>; </xmi:Extension> </type> </ownedAttribute>
Boolean from the UML PrimitivTypes package:
<ownedAttribute xmi:type='uml:Property' xmi:id='_15_0_1_275013a_1210591343275_118710_1237' name='ended' visibility='public'> <type xmi:type='uml:PrimitiveType' href='http://schema.omg.org/spec/UML/2.0/uml.xml#Boolean'> <xmi:Extension extender='MagicDraw UML 15.0' extenderID='MagicDraw UML 15.0'> <referenceExtension referentPath='UML Standard Profile::UML2 Metamodel::AuxiliaryConstructs::PrimitiveTypes::Boolean' referentType='PrimitiveType'/> </xmi:Extension> </type> </ownedAttribute>
Now this is not a problem of XMI in itself but an incapability of the vendor to hide implementation details from the user. But it is typical for the problems that arise during processing XMI files.
Best regards,
Andreas
May 13th, 2008 at 11:59 am
Hi Andreas,
Small edit issue : your text refers to int and Integer but you’re using booleans in your example.
Regarding building an import feature & primitives : I think it would only be fair to expect that anyone who wishes to export their model for use in another tool, to stick to the standard types, no?
Best regards,
Yanic
May 13th, 2008 at 11:22 pm
Hello Yanic,
thanks for taking the time to comment and pointing out the inconsistency.
I would not expect a user to be aware of the subtle differences between the three possible boolean primitives in MagicDraw and to use consistently the definition from the UML package. Maybe users who use their model for code generation would take care of this but that is only a fraction of all users.
I think a robust tool must support all possible values.
In addition, that is just a small example of the “fuzziness” of XMI that must be taken care of in a robust XMI import.
Best regards,
Andreas
July 30th, 2008 at 9:30 pm
Hi Andreas,
I’ve worked almost 5 years for a uml tool vendor in Hamburg (that should give you a hint;-) and we also supported XMI as standard format. To be honest: I’ve never fully read the XMI spec since we used frameworks like netbeans MDR and later EMf to provide a XMI mapping for us. But I think the problem is the weak UML specification. As a uml tool vendor you have to “interpret” the UML spec, which – as you said – every vendor interprests differently. So even if every tool would use the same XMI version (yes, there are a lot of different versions), each vendor still use his own interpretation of the UML spec! Thus even then no exchange between tools would be possible. And even if everyone would use the same inpretation: What about the diagram information?
I think eclipse UML2 is becoming more and more important and will allow exchange of model information via XMI. The OMG is actually collaborating with the eclipse foundation to get feedback about their standards (they had an OMG eclipse symposium this may). But even with eclipse UML2 we still are missing a XMI standard for diagram information. eclipse uses GMF that is loosely based on the UML DI standard, but there is no offical mapping for UML. And I’m not really sure if this will ever appear…
Best regards,
Matthias
July 31st, 2008 at 9:45 pm
Hello Matthias,
thanks for taking the time to comment!
Indeed, the OMG failed to provide a compact and comprehensible specification and compliance test suite for a model interchange format. That would have improved the acceptance of UML quite a bit, I think.
As far as diagram interchange is concerned, there is a specification from the OMG (http://www.omg.org/technology/documents/formal/diagram.htm) but it has even less practical use than XMI.
Probably the UML2 project/formats will just become the de facto standard.
Best regards,
Andreas
July 31st, 2008 at 11:26 pm
Hi,
Of course I know the diagram standard since ex colleagues of mine wrote it
But even with eclipse UML2 becoming the de facto standard there’s still room for interpretations. I once had a discussion with UML2 experts about how to use stereotypes with eclipse UML2 and we ended up with two ways to use eclipse UML2. So even a de facto standard doesn’t solve everything! And I think not having compliance test suites at the time of finalization of the UML2 spec opened the door for having different standards, so that it’s no already too late to solve vendor lock-ins. So UML2 never will fulfill the promise to be an interchange standard format. But perhaps the OMG will come up with UML3 in twenty years?
Best Regards,
Matthias