Why XMI Has No Graphical Layout

Mark Bell

Mar 31, 2000

Here is an Email in which I describe why XMI does not have graphical layout information.  And here is a link to a copy of the XMI spec:  XMI-OMG 98-10-05.pdf  and its appendix:  XMI-OMG Appendix 98-10-06.pdf  (These are copies stored on our Intranet.  I expect to keep this current but you may wish to go to the http://www.omg.com site for the most current copy.)  And here is an actual XMI file which Explorer 5.0 can parse:  BMWxmi.xml

Date: Fri, 31 Mar 2000 13:24:13 -0800

To: Armin

From: Mark Bell <markb@sf.aonix.com>

Subject: Re: AW: XMI and StP ?   (How the XMI Spec is Derived)

At 11:50 AM 03/31/2000 +0100, Armin Mueller wrote:

>> Our customer Sextant would like to know if we have a plan for an

>> integration of the standards-based XML Metadata Interchange (XMI) for

>> StP.  ...

>XMI as we support it at this time has a couple of limitations:

>- XMI/OMG does not define graphical information yet, Mark, any news on that ?

Your statement is correct.  There is a reason for it which I was finally

able to discover at the OMG meeting I attended in Denver. 

The XMI spec employs a Document Type Definition (DTD) as do

other XML documents.  When the parser looks at an XMI file, it

references this DTD.  In the case of XMI, this DTD is produced

automatically from the UML metamodel (MOF).  That is a major

accomplishment from the XMI maintenance perspective, since it

means that the XMI specification may be reliably and automatically

updated if the underlying UML metamodel should change.

What that means, however, is that since the UML metamodel

does not have graphical layout information in it, the XMI spec

does not either.

I have begun some investigation of the OMG XMI committee and

my ambition is to ensure Aonix is represented in this process.

Of course, I have been to exactly one OMG meeting and my name

does not end with "Amigo" but that's what we're going to be

working on at OMG!

We do have it in our power to examine the XMI spec and

construct a candidate representation for graphical layout

information.  I am not positive what the best theoretical approach

is but we should consider doing some work in this area on

a proposal basis.  This could serve some of our internal needs

as well.

The other solution would be to simply rely on automated layout

of XMI diagrams.

>Also, another problem is roundtrip. StP->Rose->StP ? A while ago IBM

>said they will offer an XMI diff which would allow a diff/merge based

>on XMI, thus not requiring the tools themselves do the job. What they

>have at this time, though is crap. I tested it, it just doesn't work

>and on top of that would require the user to understand the XMI language.

Long ago I did some investigation of a graphical “diff" capability

in the context of versioning tools.  That is, a versioning-sensitive StP

extension that would use the underlying ClearCase "diff" machinery

and offer an editor screen with indications (preferably in color) of

the differences detected by the underlying engine.  This is a

fairly sophisticated thing to build, I believe, but in an XMI world

it could be valuable.

Let me know if you would like more information.  I have the

XMI references if you wish to investigate further.

Best regards,

Mark Bell

Sr. StP Applications Engineer