| Re: [mdt-papyrus.dev] general UML 2.5 questions |
hi christian, On Thu, Oct 16, 2014 at 08:40:24AM -0400, Christian W. Damus wrote: > From a purely practical perspective, in the Eclipse implementations of both UML and (E)MOF/XMI, the snippet that you quote can be loaded and processed sensibly. > > The Eclipse UML2 project's UMLResource configures itself to load unrecognized content, including objects such as the UML-DI diagram for which the EMF run-time cannot find a containment reference (as would be the case here). An application that loads this resource would be able to find the diagram in the "extensions" of the UML package, in the resource's extension map (see the XMLResource::getEObjectToExtensionMap() API). The diagram would end up in some grab-bag feature of the AnyType that is the package's evil twin in the extension map. yes, that makes a lot of sense and is even quite extensible beyond pure UML into meta-modelling land: you will need properties that are common to XMI-stored objects anyway, even if they have nothing to do with the object as defined by the meta-model. an example would be id or URIs. So this grab-bag of extra children would be a logical extension of that mechanism. but it is a custom extension to the specification, and extending is breaking :) so the question remains: is there any way to make sense of this in the bounds of the OMG specs? In any case: I think the solution you described above is probably the best given the current state. similarily, on the other subject of the original mail, I now think that simply creating your own L0.xmi on top of the 2.5 UML that merges all relevant classes into one package is probably the best way to get around this particualr problem. again, it is extending the spec somewhat, but it is not overly intrusive... thanks robert -- Robert Lemmen http://www.semistable.com
Attachment:
signature.asc
Description: Digital signature