Community
Participate
Working Groups
We need to see how to identify EMF model objects within the workspace. Not only the resource they live in is interesting, but also the path within the model and their unique id.
There is a unique namespace URI identifying every object uniquely so no issue here.
Resolving though of course we'll need to actually implement this, that will be part of generic EMF bridge task. (TBC)
Miles, just process wise, every resolved fix bug should have a milestone set. If there is no action we usually mark bugs that turn out to be noops as duplicates or wontfix/worksforme.
That makes perfect sense. When I do resolve, I see we only have the Eclipse release train versions, i.e. 3.7. Would I just use 3.7?
The milestones are actually Mylyn versions. We finally almost caught up with the platform :). The next release is going to be Mylyn 3.7 so that's the milestone that should be used for committed bugs for the next release (tentatively planned for end of the year).
Just a note that we have to be cautious in using namespace URI. We can use it for entities but should not use it for references to *other* model features for generated EMF editors (assuming we provide such support). This is because they are unfortunately are not "robust to element order switching". See AbstractContextStructureBridge#getHandleIdentifier. Instead references point to elements, e.g.: <someClass someReference="//@somecontainer.0/@somItem.123 ..."
(In reply to comment #6) > Just a note that we have to be cautious in using namespace URI. We can use it > for entities but should not use it for references to *other* model features for > generated EMF editors (assuming we provide such support). This is because they > are unfortunately are not "robust to element order switching". See > AbstractContextStructureBridge#getHandleIdentifier. Instead references point to > elements, e.g.: > > <someClass someReference="//@somecontainer.0/@somItem.123 ..." This is the "default" case but some Ecore models will define ID's for their elements, (EAttribute.isID) or will use keys to identify the element from their containment list. One can also use XMI-ID if he relies on the XMI serialization. Using eKeys for instance makes it robust regarding order switching. I would say that this choice is the domain designer/implementor choice (each identification mechanism have pros and cons) and that the mylyn bridge should not "override" this and just use EcoreUtil.getURI().
(In reply to comment #7) > (In reply to comment #6) > > Just a note that we have to be cautious in using namespace URI. We can use it > > for entities but should not use it for references to *other* model features > for > > generated EMF editors (assuming we provide such support). This is because they > > are unfortunately are not "robust to element order switching". See > > AbstractContextStructureBridge#getHandleIdentifier. Instead references point > to > > elements, e.g.: > > > > <someClass someReference="//@somecontainer.0/@somItem.123 ..." > > > > This is the "default" case but some Ecore models will define ID's for their > elements, (EAttribute.isID) or will use keys to identify the element from their > containment list. One can also use XMI-ID if he relies on the XMI serialization. > > Using eKeys for instance makes it robust regarding order switching. Yep. In AMP for example some of the IDs are inferred from other related state and checked for semantic uniqueness. But I'm concerned about the general case because even many Eclipse EMF implementations don't support semantic and/or non-order dependent references. I'm thinking of EEF and IIR E4 for example. <elements xsi:type="eef-views:ElementEditor" xmi:id="_-lyS0mbLEeCc14hltTOYmQ" name="description"> <representation href="platform:/plugin/org.eclipse.emf.eef.views/std/SWT.toolkits#//@widgets.2"/> </elements> > I would say that this choice is the domain designer/implementor choice (each > identification mechanism have pros and cons) and that the mylyn bridge should > not "override" this and just use EcoreUtil.getURI(). Wait, do you mean that we should just use EcoreUtil.getURI() or that we shouldn't? :) [There's an old Saturday Night Live skit where the retiring nuclear power plant engineer leaves and on his way out he says: “Don’t forget, and this is critical! You can’t use too much cooling water.” Followed by much discussion and eventually, mushroom cloud..] Assuming the former, I agree that we shouldn't override the default implementation. For one thing, if the references are to external resources, we'll end up with a real hairball. In practice I can't see this as being an issue because the only real concern is the references to other objects from the source object and the only place I can think of where that might come up is in some of the more complex diagram editor implementations.
You're right, my sentence is not that clear, let's hope no nuclear plan is getting built on top of this discussion :p What I meant was : IMO you should only rely on getURI and people should update their code (starting by EEF which I'll CC ;) ) . And *we* should publicize this a bit more, it's definitely one of the top ten EMF mistakes.
