From: Martin Matula Hi Jonathan, from looking at your XMI document I can see that it is not compliant with XMI spec. at all. You are using all kinds of custom tags that are not derived from the metamodel of UML (e.g. diagrams, umlobjects, etc.). The goal of XMI is to enable interoperability. This is certainly not going to happen if every tool vendor creates various non-compliant extensions and modifications. In addition, while bigger companies (you name them) can afford to have proprietary formats for storing UML models, I think that strict adhering to standards is important for tools with smaller customer base - IMO your chance to attract people by your tool is bigger if you give them a way to interoperate with the tools they are using currently. So, the correct way of encoding extensions that are not captured in a metamodel is to enclose them into the standard xmi.extensions and xmi.extension tags. Another option is to store these extensions in a separate file (desirably also an XMI file, but conforming to the MOF metamodel of your extensions, not to UML). This way your tool will be able to interoperate with other XMI compliant tools (other UML tools, xmi2code generators, MOF repositories, etc.). -- From: Paul Clark I'm afraid I have to agree with the other poster, this is so unlike the standard UML-in-XMI (even given its legendary mutability) that I certainly can't read it, even with a highly liberal parser. It's not just the diagramming extensions which I can at least ignore, it's the structure of the core model. The first few things that break my reader are: - Lack of UML:Model element Lack of AssociationEnds in Association Use - of Associations with assoctype (?) 'generalization' instead of - Generalizations > Incidently the Free Software project http://xmi2code.sf.net sounds > similar to have you have planned. It does - thanks for that. Funny how you wait years for some decent XMI tools and then they all appear at once - like London buses... ;-) I think we're aiming in slightly different directions, though - I'm more interested in total code generation of (e.g.) O/R mappings than round-trip CASE stuff. Watch this space... I see that they have based their XMI reader on Umbrello output - that's doubly concerning, because together you're creating an incompatible fork of the XMI/UML spec. I don't want to denigrate your work on the modeller in any way, but I'm afraid this mis-implementation of XMI/UML is positively harmful and needs to be addressed quickly. For my part, I'd be happy to run some interop tests for you if you decide to move towards a more standard approach. Paul -- Date: Thu, 30 Jan 2003 11:56:54 -0000 From: Paul Clark Jonathan Riddell wrote: > However I'd be curious to know how well other UML tools can read each > other's output. Not well, it's a big problem. It partly comes from incompatible version changes both in XMI and UML, and the resulting N*M possible combinations, and partly because the XMI spec allows many (too many, IMO) options to generators - for example, whether to use attributes or sub-elements or links for properties. Also (and this isn't meant as a criticism of the XMI process, just a pragmatic observation) the way UML-XMI is derived makes it hard for mere mortals like us to jump in and use it - in theory at least you have to absorb the entire MOF infrastructure before you can write a simple class-model parser. It kind of reminds me of SGML - very powerful and general, and I was a great fan of it once I eventually grokked it - but it took XML to simplify it so you could just grab it and run before it really took off. So I'm also still feeling my way here, but I think I might be able to clarify a few things... (XMI gurus please correct me if I drift off the path too far!) Personally, I think your best bet is to go for UML1.4 in XMI1.2 - that's what Poseidon does (using the Netbeans MDR exporter), and it's somewhat friendlier than XMI1.0-based forms. It's fairly up-to-date, and at least you'll know that people can exchange your model structures (if not the diagrams) directly with Poseidon. (Beware though that I think Poseidon/MDR may have problems in the area of type references - they use subclass elements like UML:Class instead of UML:Classifier - I'm trying to check this up with them at the moment) You mention in your online diary that the (XMI 1.0) ArgoUML format looks pretty weird - that was my first reaction, too, but the differences are actually fairly superficial: - Firstly XMI1.0 uses fully package-qualified element names like "Foundation.Core.Class", whereas XMI1.1+ uses only the leaf element name and a UML namespace - "UML:Class". - ArgoUML chooses to put all 'properties' of the model element (name, isAbstract etc. etc.) into subelements like 'Foundation.Core.GeneralizableElement.isAbstract' rather than the a simple 'isAbstract' attribute. The latter choice still exists in all versions of XMI, but if you want your XMI to be human-readable (a valid desire, I think, even for something that is supposed to be an interchange format), I'd recommend using attributes for all primitive properties, and leave sub-elements only for constructed things like UML:Multiplicity. [Interop tests] > I'm sure that would be very helpful. The above hints are already very > helpful, as are those from Martin Matula. Thank you for taking this in the constructive spirit it was intended. Let me know when you come to push forward on this, and I'll see if I can help further. -- Date: Thu, 30 Jan 2003 01:56:50 +0100 From: Martin Matula Hi Jonathan, if you decide to go with the standard XMI format, we can provide you with a tool that verifies the generated XMI file for compliancy against a given UML metamodel (UML 1.3, 1.4 or 1.5 depending on which one you are implementing). > However I'd be curious to know how well other UML tools can read > each other's output. I would guess that for most tools the interoperability is quite bad as most of the tools implement UML 1.3, which contains inconsistencies between DTD and the actual metamodel. Also other problems arise from the fact that the toolvendors usually implement XMI support by hardcoding it for UML based on the DTD which is not able to fully capture all the semantics expressed in the metamodel. > (No rush on anything, next release won't be until KDE 3.2 which will > be some time.) In the meantime, it would probably be a good idea to clarify that the XML your tool produces is not XMI so that you don't set wrong expectations that could potentialy further discredit the XMI standard. Regards, Martin -- Date: Tue, 4 Feb 2003 10:12:21 -0800 From: Barbara Price To: Jonathan Riddell Subject: RE: [xmi] Repository of XMI examples (again!) Some information that I hope may help: The XMI 1.2 spec is available on the OMG web site at http://www.omg.org/technology/documents/formal/xmi.htm. I found this easily by navigating through the OMG links.... but it wouldn't surprise me if you found another way in that didn't get you to XMI 1.2. If you can recall what that was, let me know and I will try to get it fixed. ftp://ftp.omg.org/pub/xmi-test contains some test cases that you may find useful. -- Unfortunately UML 1.4 and XMI 1.2 is not an 'official' combination: XMI 1.2 applies to MOF 1.4 metamodels, and UML 1.4 is a MOF 1.3 metamodel. In practice you can of course apply the XMI 1.2 rules to UML 1.4. It's just not official: the official DTD for UML 1.4 is XMI 1.1. Other UML 1.4 tools may well fail to import a XMI 1.2 file purely because the version number is wrong. XMI 1.2 actually made very few substantive changes - it cleaned up the document a lot and catered for the new MOF 1.4 datatypes. Pete Pete Rivett (pete.rivett@adaptive.com) Consulting Architect, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com