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

["Kenn Hussey" <Kenn.Hussey@xxxxxxxxxxxxxxx>]

Piergiuseppe,

It isn't technically mandatory for UUIDs to be globally unique (and there's 
no way to enforce that), but that's certainly the spirit with which support 
for them was introduced. In fact, if you move an object between two resource 
implementations for which UUIDs are enabled, the ID for that object is 
preserved. The intent is that once an object has been assigned a UUID, it 
keeps that UUID (regardless of which resource it's attached to) until it is 
destroyed, regardless of how it changes over time.

Kenn

"Piergiuseppe Spinelli" <piergiuseppe.spinelli@xxxxxx> wrote in message 
news:67ca18393826cdbe003eebf8851e0ebd$1@xxxxxxxxxxxxxxxxxx
> 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
>
>