[Uml-devel] XMI support in Umbrello

[Marcus Alanen]

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. :-(

Regards,
Marcus