[Uml-devel] XMI support in Umbrello
maalanen at ra.abo.fi
Wed Feb 9 11:10:44 UTC 2005
Andrew Sutton 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
Dito, although I'm only talking, not coding.
> 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.
While I otherwise agree with Andrew's excellent post, I would like to
chime in with two things here:
1) there is provision for application-specific data, in the
XMI.extension node (and XMI.extensions, which is slightly different).
For some reasons it might be very awkward to use, though. I think tools
need to know the DTD of the application-specific data to be completely
sure they can handle some things correctly, but I am not an XM_L_ expert.
2) There is a standard way to describe diagrams, the XMI Diagram
Interchange (XMI-DI) format, *but* there is no official mapping between
UML abstract constructs to their corresponding diagram elements. What
we've done in Coral is mimic Gentleware's Poseidon. This is kind of OK
since it is currently the only tool (+ Coral) which supports XMI-DI that
I know of, although official OMG-endorsed mappings would naturally be
preferable and obligatory if using XMI-DI is to take off. And thus there
is no telling how to do the same for UML 1.3 or even the new UML 2.0.
On the other hand, XMI-DI + models might require XMI 2. This isn't
really my primary concern since tools don't seem to get even basic
abstract data serialisation correct.
> 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
Oliver has been working on this, so at least exporting is a lot better,
but I'm sure he can answer this more thoroughly. I do agree that a
tool's internals need to be built towards making export/import easy and
I'm afraid that this leads to huge amounts of "unnecessary" work if it
isn't taken into account from the beginning. :-(
More information about the umbrello-devel