[news.eclipse.modeling.mdt.uml2] Re: Preserving uuid to xmi:id mapping c

[piergiuseppe.spinelli@xxxxxx (Piergiuseppe Spinelli)]

Hi Kenn, 

I apologize if I return again on this point, just to ask one clarification 
(not to argue, really just to better undertand)

You said: "Given that UUIDs are supposed to be globally unique (that's why 
they're useful), I'm not sure it would be a good idea to assign the IDs of 
UML elements to the resulting Ecore elements"

Now this made me wander a couple of things:
- does "UUIDs are globally unique" mean than every time you serialize the 
same uml document to different files it is mandatory to generate new UUIDs?

In my opinion this is not required, since the role of UUIDs should be to 
sign with an unique value, w/o any business meaning by itself, the unique 
identity of an element (i.e. an UML Class or Property).

So, when the same element it is serialized again & again (and this means, 
the same identity, even if some of its properties has been modified or its 
position in the document has changed) it could be right to use the same 
UUID since it is the only thing granting the identity of the element along 
the time.

Using URI fragments, instead (in my opinion, but I ask for yours), 
identify an elements just in a specific context and are not always able to 
keep its identity along the time (i.e. when some other sibling is inserted 
before it, or it is renamed or moved under onother package, and so on)

Finally, the unicity of an UUIDs shoud be granted just in the space of all 
the UUIDs: this shoud not refrain to use the same value (or a derived one) 
in the space of XMI:ID of its ecore translation, since (1) XMI:IDs are not 
UUIDs (2) they need to be unique just inside a model.

At the end, a concrete example: 
I've been involved in these last years, on the behalf of the bigger 
italian Telco, in the processes for adopting the SID (the reference model 
for the Telcos by the Tele Management Forum).
SID is a very (really very) large UML document that needs to be extended 
in order to be adopted in the real word, and it can be used in a lot of 
ways: one of them is as an hub in the semantic reconciliation among the 
different models used in the enterprise. This task requires a map between 
the SID entities and each matching element in the different data sources.
Now, every time the extended SID is modified (or a new version is released 
by the TMF), all this huge mass of work should be revisited: this would 
make the governance impossible in facts.
Now, if the impact analysis of a new SID version takes care of UUIDs and 
they are preserved across the successive versions, the job becomes 
possible!

As you see, this could be a very important and not "philosophical" 
question.
Since I have choosed Eclipse and EMF as the best among the current 
tecnologies to gring models and metadata, I look forward for opinions 
about that from you and every other guy interested in this matter.

Thanks,
   Piero



Kenn Hussey wrote:

> Piergiuseppe,

> Given that UUIDs are supposed to be globally unique (that's why they're 
> useful), I'm not sure it would be a good idea to assign the IDs of UML 
> elements to the resulting Ecore elements (although it would be possible by 
> calling the conversion utility programmatically, using a custom resource to 
> load the Ecore model, and setting the XMI IDs of the Ecore elements based on 
> the UML element on which they were based). I would suggest producing a 
> mapping from UML element URI fragment (GUID) to Ecore element URI fragment 
> (name-based path) by processing the map that is returned after the 
> conversion and doing a reverse look-up to assign the desired IDs to UML 
> elements if/when the Ecore representation is ever converted back to UML...

> Kenn

> "Piergiuseppe Spinelli" <piergiuseppe.spinelli@xxxxxx> wrote in message 
> news:66dcd6dc89d0595eed9e551934c1185b$1@xxxxxxxxxxxxxxxxxx
> > Hi,
> >
> > I'm building an EMF based Eclipse application and I am currently using the 
> > existing UML to EMF converter from the ide.
> >
> > How can I preserve the uuids in the original uml file forcing them to be 
> > the xmi:id of the generated EClasses, and EStructuralFeatures?
> >
> > My UML tool assures to preserve the same uuid for the same element (even 
> > if it is, let's say, moved to another package) across different exports, 
> > so using uuids it is possible to perform more accurated comparisons of 
> > generated eCore models that, i.e., do not exange a moving operation for 
> > two unrelated operations (delete of the existing element and creation of a 
> > new one).
> >
> > Thank for any help