Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [] Observations on QVT 1.2 UML 2.5 XMI files

Thanks for the feedback, Ed. If I'm not mistaken, most/all of these are already accounted for by using the appropriate resource implementation in UML2 (i.e., XMI2UMLResourceImpl) like the sample UML editor does.


On Tue, Mar 25, 2014 at 9:05 AM, Ed Willink <ed@xxxxxxxxxxxxx> wrote:

Hi Kenn

I used the latest UML 2.5 tooling to produce the new models for QVT 1.2 and it all seemed to go quite well, until Pete Rivett reviewed the *.xmi models.

Rather than raise Bugzillas directly I've listed his observations below, since the difficulties are borderline between sensible Eclipse UML practice and strict OMG XMI expectations.

My *.xmi approach was to convert oppositeRoleName-EAnnotated *.ecore files into *.uml files then relocate the UMLResource.contents into corresponding XMIResource.contents to get a simple *.xmi save.

The 500 lines of Java can be seen in /org.eclipse.qvt/src/org/eclipse/qvt/tools/ in the QVTd GIT.

The Save options allowed most things to be configured. The main 'nasty' of renaming the UML namespace could be acheived by a BasicExtendedMetaData.getNamespace 'lie'.

Pete's obervations.

Don't use xsi:type: easily fixed with XMIResource.OPTION_USE_XMI_TYPE

Remove xmi:version - redundant in XMI 2.4. This seems to be a bug in XMISaveImpl, where perhaps a null xmiVersion could be used to signal no attribute. Removing this during serialisation defeated me so I have had to add a text filtering pass on the final files.

Use Package not Model at root of UML metamodels - this is a MOF rather than UML constraint so perhaps it has been overlooked. Fixed by a Ecore2UMLConverter.caseEPackage override.

Provide redundant xmi:type on root elements - a new requirement of XMI 2.4. Fixed by an override on XMISaveImpl.saveElementID.

Omit derived classifier property for EnumerationLiterals - changing to use UMLSaveImpl rather than XMISaveImpl fixed this, but I'm puzzled by the special case processing for EnumerationLiteral. It is understandable that XMISaveImpl gets this wrong since it may lack the understanding of UML EAnnotations that identify the 'duplicates'. However surely UMLSaveImpl should be detecting attributes that are derived as a consequence of a 'duplicates' EAnnotation rather than special casing the known EnumerationLiteral.classifier property?


Ed Willink

_______________________________________________ mailing list

Back to the top