Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Why is the Ecore iD attribute scoped to the resource?(EMF resource semantics)
Why is the Ecore iD attribute scoped to the resource? [message #1855603] Sun, 23 October 2022 08:50 Go to next message
Jörn Guy Süß is currently offline Jörn Guy SüßFriend
Messages: 320
Registered: July 2009
Location: Anstead, Brisbane, Queens...
Senior Member

I understand that the iD flag of EAttribute indicates that the value of that attribute is a unique identifier of the EObject in the containing resource. It is that last part that I am struggling with.

If Ecore models are defined conceptually and the Resource abstraction is meant to protect the storage aspects, why is iD's definition referring to the Resource scope?

Does this not create a problem if a model is moved from one resource to another, and embedded, so the iD property does not hold any more?

Or does the ID property have to hold in every resource that implements storage for this EClass. Feels like the iD property then is a UUID?
Re: Why is the Ecore iD attribute scoped to the resource? [message #1855604 is a reply to message #1855603] Sun, 23 October 2022 09:22 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33143
Registered: July 2009
Senior Member
Yes, ID attributes have limited usefulness and it's difficult to maintain their uniqueness.

The concept mirrors what's provided via xml:id, i.e., "the value is unique within the XML document, and that each element has at most one single unique identifier":

https://www.w3.org/TR/xml-id/

In EMF document == resource.

Yes, if you move or copy an element with an ID you are likely to violate the constraint.

The constraint is implemented like this:
  public boolean validate_UniqueID(EObject eObject, DiagnosticChain diagnostics, Map<Object, Object> context)
  {
    boolean result = true;
    String id = EcoreUtil.getID(eObject);
    if (id != null)
    {
      Resource resource = eObject.eResource();
      if (resource != null)
      {
        EObject otherEObject = resource.getEObject(id);
        if (eObject != otherEObject && otherEObject != null)
        {
          result = false;
          if (diagnostics != null)
          {
            diagnostics.add
              (createDiagnostic
                (Diagnostic.ERROR,
                 DIAGNOSTIC_SOURCE,
                 EOBJECT__UNIQUE_ID,
                 "_UI_DuplicateID_diagnostic",
                 new Object []
                 {
                   id,
                   getObjectLabel(eObject, context),
                   getObjectLabel(otherEObject, context)
                 },
                 new Object [] { eObject, otherEObject, id },
                 context));
          }
        }
      }
    }
    return result;
  }
So every resource is expected to support looking up an object by its ID. For two resources r1 and r2 there is no requirement that r1.getEObject(id) and r2.getEObject(id) can't both be return non-null different objects. In other words, resources can reuse IDs.


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Why is the Ecore iD attribute scoped to the resource? [message #1855605 is a reply to message #1855604] Sun, 23 October 2022 10:03 Go to previous messageGo to next message
Jörn Guy Süß is currently offline Jörn Guy SüßFriend
Messages: 320
Registered: July 2009
Location: Anstead, Brisbane, Queens...
Senior Member

Ok. That explains it. I had read that code, but not thought that implication through to the end. Very helpful. Reason I am asking is I see a lot re-invention happening with people doing resource management at a second tier when EMF already has what seems excellent resource management and clean semantics built in. So I am trying to write an article to cohesively explain this. Especially features like IDs and resolution/canonisation are core to all larger applications and I feel they are often ignored.
Re: Why is the Ecore iD attribute scoped to the resource? [message #1855606 is a reply to message #1855605] Sun, 23 October 2022 10:27 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33143
Registered: July 2009
Senior Member
Note too XMLResourceImpl supports UUIDs too (if org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.useUUIDs() is specialized to return true, and then will manage extrinsic IDs for the resource.

Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Why is the Ecore iD attribute scoped to the resource? [message #1855607 is a reply to message #1855606] Sun, 23 October 2022 11:03 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

Yes IDs have limited usefulness. I don't think I have found a practical use where I used them and didn't discard them again.

EMF's approach is sensible from an efficiency perspective in that a single lookup finds everything without hierarchical traversals or long names at the modest XML cost of a defining attribute. Since the ID is qualified by the Resource URI, moving between resources is not a problem. Obviously the mover is responsible for reallocating the ID. More generally, there is a strong case for erasing all IDs on load and regenerating on save. The UML2 project does this. Unfortunately this requires all referencing models to be rewritten.

EMF's approach is confusingly different to UML's where the ID is unique wrt the parent scope, enabling use as a 'map' key. It would be nice if this functionality was available rather than relying on the few places where there is a built-in knowledge of a 'name'.

IMHO UUIDs offer the worst of nearly all worlds; long and unreadable and still not valid for a migration that is potentially an illicit clone. They are of course globally unfindable without the qualifying resource URI.

If you are writing up the results of some research you might care to search for a couple of my postings on LUSSIDs; Locally Unique Structurally Sensitive IDs that can accommodate a certain amount of refactoring without the fragility of EMF's hierarchical IDs.

Regards

Ed Willink
Re: Why is the Ecore iD attribute scoped to the resource? [message #1855612 is a reply to message #1855607] Sun, 23 October 2022 13:45 Go to previous messageGo to next message
Jörn Guy Süß is currently offline Jörn Guy SüßFriend
Messages: 320
Registered: July 2009
Location: Anstead, Brisbane, Queens...
Senior Member

Thanks for the detail. I did not mean to take up that match of your time! This has helped. If you care, I am happy to provide draft of the document. I assume that the LUSSIDs are essentially a type of semi-structured hash? I have not found the reference using a web search, so I cannot add this, but will reference this discussion thread.
Re: Why is the Ecore iD attribute scoped to the resource? [message #1855617 is a reply to message #1855612] Sun, 23 October 2022 16:10 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

Yes a semi-structured hash. Expression trees and some class-structure downwards. Sometimes upwards.

Unfortunately the EF has restructured its websites so that Google no longer indexes them. Googling "Willink LUSSID" gets only one hit whereas searching my Thunderbird forums gets 10. I thought one of them had some detail but seemingly not.

Earliest: https://www.eclipse.org/forums/index.php/mv/msg/1090495/1778078/#msg_1778078

Best context: https://www.eclipse.org/forums/index.php/mv/msg/1106430/1836306/#msg_1836306

Best reference: https://www.eclipse.org/forums/index.php/mv/msg/1097064/1801234/#msg_1801234

Maybe the detail in the Java comments is ok, but as with all comments perhaps stale.

Regards

Ed
Re: Why is the Ecore iD attribute scoped to the resource? [message #1855618 is a reply to message #1855617] Sun, 23 October 2022 20:33 Go to previous messageGo to next message
Jörn Guy Süß is currently offline Jörn Guy SüßFriend
Messages: 320
Registered: July 2009
Location: Anstead, Brisbane, Queens...
Senior Member

Another one along the same lines. Assuming I would like to reuse the setUUID() mechanism in XmlResourceImpl, but render a different output syntax, what would be the correct way to contribute the concrete syntax rendering for the alternate notation. It seems it would be org.eclipse.emf.ecore.xmi.DOMHandler and org.eclipse.emf.ecore.xmi.DOMHelper. Is that correct? How does the override look for this case?
Re: Why is the Ecore iD attribute scoped to the resource? [message #1855621 is a reply to message #1855618] Mon, 24 October 2022 07:11 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 33143
Registered: July 2009
Senior Member
You'd want to specialize org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID(EObject) and, to read what you saved, org.eclipse.emf.ecore.xmi.impl.XMLHandler.handleObjectAttribs(EObject).

Ed Merks
Professional Support: https://www.macromodeling.com/
Previous Topic:Handling of very large model instances
Next Topic:Export ECore to XSD
Goto Forum:
  


Current Time: Thu May 02 01:20:02 GMT 2024

Powered by FUDForum. Page generated in 0.04774 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top