Re: ocl conformance test

Date view Thread view Subject view Author view Attachment view

From: Stefan Haustein (
Date: Sun 15 Feb 2004 - 20:57:17 GMT

Hi Laurence,

I agree that support for XMI in tools is still far from perfect.

However, most tools claim to be able to read XMI. Perhaps the 
availability of a vendor-neutral OCL conformance test file would 
encourage vendors to fix their XMI support---at least to a level that 
allows to read the test file. As you say, part of the problem is that 
there is no such test.

Concerning XMI itself: In my opinion, the worst part of XMI is that 
properties are qualified with the full name of the declaring classifier, 
which makes all properties globally unique. This is required to build a 
reasonable DTD, but not for XML Schema. When importing XMI, one can 
simply cut off anything to the last dot (that is what I do), but that 
does not help for writing XMI (so I cannot write XMI because its just 
too expensive and not essential for my application).

Ideally, a new version of XMI would simply build on the SOAP 
serialization rules, so one does not need to implement two different 

BTW: I am using MagicDraw to generate XMI files because it uses XMI as 
its native storage format, so I can never forget to export after 
modifying a model.... :)

Best regards,

Laurence Tratt wrote:
> On Thu, Feb 12, 2004 at 10:45:01AM +0100, Steffen Zschaler wrote:
> [Jörn]
>>>I agree, but your approach tacitly assumes that tools will be able to read
>>>XMI-Files and (moreover) extract the statements from them. IMO this is
>>>rather the exception than the rule.
>>This seems to be putting the barrier pretty low. Any OCL tool will need to
>>be able to access UML models in some manner. The two standard approaches
>>would be either by accessing some kind of model repository or by reading in
>>XMI files.In the latter case the ability to read in XMI files is implicitly
>>given, while in the former case most UML repositories support filling the
>>repository from an XMI file. So, I think its a pretty low barrier already
>>to be able to read in XMI files.
> That's certainly what would happen in an ideal world. About 18 months ago I
> investigated a number of commercial and open source UML tools, as I was
> writing an XMI exporter for a research tool we had at King's College. What I
> found shocked me somewhat: I tried something like 7 or 8 tools. None of them
> did what I would consider to be a good job. 2 or 3 generated XMI which
> wouldn't even validate against the DTD, the most basic check there is. One
> tool even managed to generate XMI which its own crummy importer couldn't
> read back in.
> Even for those tools which generated XMI valid against the DTD, pretty much
> all of them violated other requirements not captured in the DTD. In the end,
> the only standard there was that they could generate XMI which Rose could
> read in [actually, there were a couple of situations when even this wasn't
> true]. The XMI importers were mostly very poor, and for anything other than
> a ridiculously simple model, the chances of exporting XMI from one tool and
> importing into another were close to nil.
> Part of the problem for this is that the XMI standard isn't a great one in
> the first place and that worse there has been no checking that tools
> actually conform to the standard in any way - people in the OMG are well
> aware of these problems and the claim is that they will be fixed, presumably
> at some point when UML 2 is finalized.
> From Jörn's comment, I would assume that the position of 18 months ago still
> holds roughly true today - that is that tools mostly operate in their own
> little bubble with very, very limited practical interoperability with the
> outside world.
> Yours,
> Laurie

Date view Thread view Subject view Author view Attachment view