Community
Participate
Working Groups
It is very easy for the same meta-model to be loaded in different ways by different aspects of meta-modeling. e.g. http:/project/model/... for a registration platform:/plugin/project/model/... for a plugin platform:/resource/project/... for a project ../../project/model/... for a relative project /project/model/... for an absolute project some of these can be made equivalent by e.g. EcorePlugin.computePlatformURIMap but unfortunately many tools neglect to call it. When a ResourceSet contains two such synonym Resources, the user will usually encounter some strange failure that an EClass A instnace is not an instance of EClass A. In OCL this may be a failure in oclIsKindOf. It is probably not possible for EMF to change the behaviour of ResourceSet to diagnose two EPackages with the same (non-null) nsURI without upsetting some existing usage. Similarly it is probably not possible for URIConverter to look harder for synonyms. So it may fall to OCL as the most general meta-modeling rather than modeling tool to diagnose this. The introduction of the pivot meta-model provides an opportunity to solve this. The incoming Ecore/UML meta-models are adapted to a composite pivot meta-model. At this point synonyms can be detected and diagnosed and merged so that code activasing the pivot meta-model gets a diagnosis, and code using the pivot meta-model gets a workaround.
Equally baffling for the user and not sensibly correctable by EMF is when the same meta-model is used statically by one aspect and dynamically by another. In this case the static version was not necessarily ever loaded as a resource so no form of ResourceSet or URIConverter processing will help. It must be meta-model tools that detect the schizophrenia.
Created attachment 177685 [details] Sample projects exhibiting an issue with what appears to be oclIsKindOf and meta model synonym
WORKSFORME. When I run the launch config on a Modeling EPP installation I get: "It is a Family". so oclIsKindOf has succeeded. I can see opportunities for confusion between family/Family as modeltype/Package/Class name. Under what circumstances does your example fail? Did you restart Eclipse to check that your failure was reproducible? I think I've seen QVTo caching old meta-models.
I've tried tried genmodelling and cannot make your ZIP go wrong. I've disambiguated the family and it still works as if(ro.oclIsKindOf(FamilyModel::FamilyClass) and ro.oclIsKindOf(familyPackage::FamilyClass)) then { log("It is a Family"); ... which clarifies that both model-type and package qualification are working. Your original newsgroup query concerned no response from family.rootObjects()[Family::Family]->forEach(ro). Family::Family is very suspect. Re-use of a name within its own namespace is at best ill-advised since many languages prohibit re-use so that A::A::A::A is A! How OCL QVTo allows Family::Family is dubious; I strongly suspect it resolves to the model-type not the Class. Whether M2M/QVTo correctly supports this corner of the spec is also dubious. But it looks as if M2M/QVTo is doing what I would expect. The problem was not that oclIsKindOf failed, but that no candidates where available for selection.
Angel: You probably want to configure your Bugzilla preferences to auto-add yourself as a CC for a Bugzilla you comment on.
Further information reveals that the problem is reproducible in Debug mode only (Bug 324054 raised for this against M2M/QVTo). Concerns about static/dynamic mixing are handled by EMF's dynamicIsKindOf. This MDT/OCL bug remains open to handle the discussed diagnosis of meta-model schizophrenia.
Another form of meta-model schizophrenia arises with xsi:schemaLocation. Fortunately this one only bites on developers, but bites hard. If the run-time workspace contains an old/stable/released copy of e.g. http://family/1.0 that is registered via an extension point, and the develoipment workspace contains e.g. platform:/resource/Family/Family.ecore, then a load of the following development workspace XMI: <?xml version="1.0" encoding="ASCII"?> <familyPfx:FamilyClass xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:familyPfx="http://family/1.0" xsi:schemaLocation="http://family/1.0 platform:/resource/Family/Family.ecore"/> loads the development workspace XMI against the run-time Ecore; the xsi:schemaLocation is ignored. This is not wrong since the xsi:schemaLocation is only a hint, but it is very unhelpful to developers who might hope to have a coherent development workspace using development resources. The problem is particularly confusing if the development Family.ecore differs from the run-time meta-model. In this case a ClassNotFoundException may arise while reading the XMI. Of course the development time workspace should never have incompatible meta-models with the same URI! But they do, because otherwise every URI reference has to be changed. NB Ecore.ecore has had many changes without ever changing its URI. Perhaps EMF should have a workspace preference option so that all model loading favours development-time over run-time resources. Developers could set it and get better behaviour. Normal use would be unaffected.
It does seem nice to have an option to force the xsi:schemaLocation to be more than a hint.
Got a similar problem when playing with Dresden's uml_wfrs.ocl and UML.ecore which has two different kinds of reference to the one meta-model;. Also XMLType.ecore which is auto-generated wrong. Pivot tries to cache a package URI to EPackage map, but these don't work until the wrong resource is read.
This problem may go away with the pivot model, since all pivots are in a single ResourceSet and equi-URI packages are 'merged' so competing definitions are detectable/ignorable.
(In reply to Ed Willink from comment #10) > This problem may go away with the pivot model The problem can never go away. Sometimes you even want both. e.g. using the installed Pivot for tooling that generates a new Pivot. StandaloneProjectMap now has conflict resolution strategies so that the appropriate handler can be configured.
When working with OCL tooling the StandaloneProjectMap supports redirection of multiple variants of the saem nsURI to just one. Conflicts are diagnosed. The original problem was therefore fixed in so far as EMF allows years ago. Bug 547835 addresses the need to improve usability.
