Bug 369264

Comment 1 Mickael Istria 2012-01-20 13:14:52 EST

The following branch contains an "AffiliationTest" class that explicit the use-cases in 2 failing test-cases.
https://github.com/mickaelistria/EMF/tree/369264

Comment 2 Ed Merks 2012-01-23 06:34:46 EST

I'm not a git expert.  I really don't know what to do with this git link.  I also don't have a lot of free time...

I doubt this is really a bug.  Only features from a document root can be affiliated.  You can make a feature map corresponding to a very permissive wildcard that allows elements from any namespace thereby allowing you to add new features from a new package with a new document root.

You can see how BasicExtendedMetaData.demandFeature creates such new features on demand in order to support lax wildcards.

Comment 3 Mickael Istria 2012-01-23 08:22:40 EST

(In reply to comment #2)
> I'm not a git expert.  I really don't know what to do with this git link.  I
> also don't have a lot of free time...

I'll attach it as a patch then.

> > I doubt this is really a bug.  Only features from a document root can be
> affiliated.

Ok, so this is not a bug. This is rather a limitation. Is it a necessary one? Could we get rid of it to allow more power inside EMF ?

> You can make a feature map corresponding to a very permissive
> wildcard that allows elements from any namespace thereby allowing you to add
> new features from a new package with a new document root.

I already tried this, but found it too difficult and constraining for my use-case. The use-case is to be able to specify a target feature map from a dynamic attribute.

> You can see how BasicExtendedMetaData.demandFeature creates such new features
> on demand in order to support lax wildcards.

I'll have a look at this.

Comment 4 Mickael Istria 2012-01-23 08:23:54 EST

Created attachment 209909 [details]
Test case, as a patch

Patch in Git Format.
Apply with "git apply".

Comment 5 Ed Merks 2012-01-26 05:04:26 EST

Just the fact that you've done this:

		// Make extension featureId to -1 to make them dynamic
		((EAttributeImpl)TestExtensionViaAffiliationPackage.Literals.EXTENSION_TYPE__EXTENSION1).setFeatureID(-1);
		((EAttributeImpl)TestExtensionViaAffiliationPackage.Literals.EXTENSION_TYPE__EXTENSION2).setFeatureID(-1);

makes it glaringly the case that you've strayed off the beaten path.  EMF generates an feature of ID -1 only for features of a  document root for a reason.  Only features of a document root can be affiliated with classes that don't actually own the feature (the feature is not among the eAllStructuralFeatures).

Next you've forced something that isn't a document root to be one anyway but giving it a blank name.  

Sorry but EMF is not intended to be used this way.  You'll need to define a proper document root in a package of its own.

Comment 6 Mickael Istria 2012-01-30 04:53:00 EST

Ok, Then I gave some tries using a Mix of static EMF and features created dynamically using EcoreFactory.
Everything would work fine if there was not this "isDocumentRoot(eStructuralFeature.getEContainingClass())" check. (In this use case "work fine == add dynamic feature to static type, if necessary through feature maps")

What does this check avoids? Why preventing features to be added to items that are not DocumentRoot?
I think this is the core of the EMF-Facet project: provide extensibility to existing model items. And I now think this simple check is the only thing that prevents EMF to support this.

Comment 7 Ed Merks 2012-01-30 05:32:58 EST

This check ensures that only features *from* a document root, i.e., features corresponding to global element declarations in an XML Schema, can be used in wildcards. It's not guarding what such features can be added to; the wildcard information (the allowed namespace) will guard for that.  When deserializing XML this type of information is important, i.e., the lookup  for the feature has to find a package for the namespace, the document root for that package, and then find the feature with that name in the document root.