Eclipse Community Forums: EMF » Why is the Ecore iD attribute scoped to the resource?

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 04:50

Eclipse User

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 05:22

Eclipse User

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.

Re: Why is the Ecore iD attribute scoped to the resource? [message #1855605 is a reply to message #1855604]

Sun, 23 October 2022 06:03

Eclipse User

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 06:27

Eclipse User

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.

Re: Why is the Ecore iD attribute scoped to the resource? [message #1855607 is a reply to message #1855606]

Sun, 23 October 2022 07:03

Eclipse User

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 09:45

Eclipse User

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 12:10

Eclipse User

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 16:33

Eclipse User

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 03:11

Eclipse User

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).

Previous Topic:	Handling of very large model instances
Next Topic:	Export ECore to XSD

Goto Forum:

-=] Back to Top [=-

Current Time: Wed Jul 02 03:00:33 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter