[Uml-devel] XMI support in Umbrello
asutton at cs.kent.edu
Wed Feb 9 08:47:52 UTC 2005
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
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
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
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
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.
asutton at cs.kent.edu
More information about the umbrello-devel