|Re: Keeping xmi:id for migration [message #1719492 is a reply to message #1719406]
||Fri, 08 January 2016 10:50
| Ed Willink
Registered: July 2009
xmi:ids are an artefact of XMI serialization of your model. If you
persisted your model in a database there might be no xmi:ids to worry about.
xmi:ids are not part of your model and so model transformation tools
ignore them (trash them).
It is possible to use blackboxes to escape to Java and access / enforce
an xmi:id. These facilities might already exist.
However since xmi:ids are not a modeling concrept, it seems a mistake to
pollute the transformation.
IMHO the best approach is to have a deterministic xmi:id generator.
Attached is one of the files for QVT 1.3 whose xmi:ids are auto-generated by
This is invaluable since it ensures that after a *.ecore update the
*.uml has stable xmi:ids and so the Papyrus diagrams are affected only
by the changed parts of the model.
NB the above xmi:id generator is simplistic since the complexity of the
UML in the QVT metmodels is limited.
Another approach that I take, when using UML as my source models, is to
re-assign all the accidental xmi:ids from Papyrus / UML2 so that my
subsequent toolchain sees stable xmi:ids.
See for instance
Imposing algorithmically determinate xmi:ids gives you control and some
immunity to metamodel changes such as SysML. But beware that generating
determinate and distinct xmi:ids for the most obscure possibilities of
overloaded operations with nested templates types is non-trivial.
Unfortunately most users only discover the benefit of determinstic
xmi:ids after a legacy of models using indeterminate xmi:ids has been
An alternative approach is to just use the *.qvttrace file from the
transformation execution to identify the input/output pairing. It is
probably less than 20 lines of Java to get all the input xmi:ids and
poke them on to the outputs.
On 07/01/2016 16:43, Francois Le Fevre wrote:
> Dear all,
> I am new to the QVTo world.
> I am facing a difficulty in the SysML composant of Eclipse papyrus
> I would like to develop a qvto for migrating my initial sysml model in
> SysML1.1 metamodel into SysML1.4.
> First at all: XMI:ID and URI
> I would like to keep the initial xmi:id / uri of my initial elements?
> or do I need to implement a blackbox?
> Secundly: switching namespace
> The majority elements of the source metamodel have a direct linked
> with the target metamodel. The only differences is the namespace uri...
> So if I have initial element of type Requierement in the namespace
> SysML 1.1, is their a qvto transformation/function to switch it
> directly into a second namespace, (also Requirement but in SysML 1.4
> namespace), keeping everything else?
> Thanks for your idea.
Powered by FUDForum
. Page generated in 0.01448 seconds