[Uml-devel] XMI support in Umbrello

[Andrew Sutton]

On Wednesday 09 February 2005 08:41 am, Anna Persson wrote:
> Dear Umbrello developer team,

although i'm not exactly part of the umbrello dev team, i do eavesdrop and 
occasionally (i.e., rare occasion) have something to contribute - like the 
big chunk of code that was umbrello2. i also built a modeling library (the 
OMF or Open Modeling Framework) that implements a bunch of OMG stuff like 
MOF, UML and particularly, XMI. if you want to take a look its at: 
http://www.sdml.info/projects/omf/. just be aware that its not an 
application, just a library.

although i do have a pretty good working knowledge of XMI and why it is or 
isn't portable between various applications. so if you're interested, i 
thought i might add my own comments.

> As shown in the document, the results are rather discouraging for most
> of the tools. As our goal is to investigate and report on the state of
> XMI interchange at the current time, we felt it important to contact
> tool developers for possible input. So, in the context of the results we
> would like to ask three questions about XMI support in Umbrello, and
> would appriciate any comments you might wish to make.

interesting results. expected, but still interesting.

> - What is the main motivation for using XMI as the saving format in
> Umbrello?

ideally, XMI is a standard so if a number of different people implement the 
standard, then they're stuff should automatically work together. 

> - We are somewhat suprised by the results, both for import and export.
> Do you have any comment to make on XMI support in Umbrello on the basis
> of the results in our ongoing study?

the primary factor affecting both import and export is actually going to be 
conformance to the OMG's UML metamodel specification. it defines what can 
actually go into a UML XMI document. if you don't (at least partially) make 
your applications internal data model resemble that of the UML specs, then 
you end up with a mapping problem from your semantics to theirs.

plus there's the other issue of additional data - specifically diagrammatic 
information. the current XMI (1.x) specs include no provision for 
diagrammatic or application specific data in the XMI file. a lot of 
applications (unless their imports are REALLY well built) will choke on that 
additional data.

i remember looking at the XMI export code for umbrello a couple of versions 
ago and it actually imposed some fairly strict structure on the internal 
organization of the XMI document. XMI imposes only a very limited 
organizational structure. there's the document, a header and some contents. 
any additional information can just get in the way - unless its built in an 
XMI-compliant fashion.

i might also note that older versions of argo produce incorrect XMI - if i'm 
remembering correctly. incorrect namespacing. they used the java scoping in 
the XMI element names (e.g., UML.Class) when it should have used XML scoping 
(UML:Class). since argo has become synonymous with open source and UML, i 
would not be surprised if the import filters from other applications had 
adjusted to respect that element tagging convention. i haven't looked in a 
while, so i'm not entirely sure if this is true any more.

> - Do you have any further comments regarding the results in our ongoing
> study, or your own experience of XMI interchange between tools?

just a question... how are you dealing with the two versions of XMI. XMI 2 is 
actually a radically different format. it's actually a little bit more 
precise. i like it better. the OMG is also putting out model interchange 
specs as well. it might be interesting to see how those are integrated into 
these applications.

i'd like to point out that the XMI specification (like most of the OMG's 
modeling specs) don't actually describe any kind of conformance criteria. a 
number of other specifications (e.g., ISO stuff) will describe levels or 
profiles of conformance to some specification. that's what makes them 
standards. XMI is the standard that isn't.

andrew sutton
asutton at cs.kent.edu