Eclipse Community Forums: EMF » Ecore Inheritance in the same Namespace

Help

Home

Home » Modeling » EMF » Ecore Inheritance in the same Namespace

Show: Today's Messages :: Show Polls :: Message Navigator

Ecore Inheritance in the same Namespace [message #1818770]

Fri, 27 December 2019 19:32

Robert Schulk

Messages: 68
Registered: July 2015

Member

I have got a fairly large ecore model.
Now, I need the same model again, but with a slight change in its content (one reference shall point to a different class).

So basically like this:

ModelA:
ClassA
=> myRef (reference to class X)
(...) many more classes

ModelB:
ClassA
=> myRef (reference to class Y)
(...) the same classes as A

My initial idea was to create a base-ecore model from which both: ModelA and ModelB inherit. The only problem is, that I need to read in existing XML files which were created with ModelA. Referencing a base-ecore would always require to use a different namespace, correct? Is this possible in a different way?

Report message to a moderator

Re: Ecore Inheritance in the same Namespace [message #1818782 is a reply to message #1818770]

Sat, 28 December 2019 07:28

Ed Merks

Messages: 30916
Registered: July 2009

Senior Member

Yes, every Ecore model needs a unique nsURI, so refactoring a model into different EPackages isn't generally going to make an older serialization readable against a pre-refactored model.

What if any is the inheritance relationship between X and Y?

One approach is to keep the older model around as a dynamic model and read older serializations based on that. Then you can transform the instance from the old model to the new model (with a new nsURI) on the fly..

Report message to a moderator

Re: Ecore Inheritance in the same Namespace [message #1818784 is a reply to message #1818782]

Sat, 28 December 2019 09:12

Ed Willink

Messages: 6595
Registered: July 2009

Senior Member

Hi

The strictness and consequence of inflexibility of metamodels is perhaps their greatest weakness for which a number of tools have some accommodation. e.g Epsilon's migrate language, ATL's nsURI blindness, QVTo's non-strict, Edapt.

Your particular change to a single reference looks like it might have a simple common abstraction solution. However, I suggest you step back and consider how, now that you have one requirement for for a flexibility, you will accommodate your next ten such requirements. In particular identify what is absolutely guaranteed not to change and factor that out as a common facility while other things support an appropriate variation point.

As Ed M points out, loading the 'wrong' metamodel can be facilitated by a dynamic copy of the 'wrong' metamodel. If your usage is critical you could even have static variants of both/all. Converting between similar metamodels is quite easy in Java where the EcoreUtil.Copier can have a basic override to accommodate the regular 'copy' policy and a few variants to handle the irregularities. Doing the same with modeling tools is disappointingly hard.

Alternatively if the variations are manageable you can avoid creating 'wrong' objects and copying to 'correct' objects by using the XML loader's support for recording unknown features so that where possible the 'correct' objects are loaded directly; you just have to fix up the obsolete usage from the unknown feature reports.

Regards

Ed Willink

Report message to a moderator

Re: Ecore Inheritance in the same Namespace [message #1818790 is a reply to message #1818782]

Sat, 28 December 2019 12:10

Robert Schulk

Messages: 68
Registered: July 2015

Member

>What if any is the inheritance relationship between X and Y?

The elements are unrelated in terms of class hierarchy. Actually, what we are doing is to remove featuremaps from the model to be compatible to CDO.

>One approach is to keep the older model around as a dynamic model and read older
>serializations based on that. Then you can transform the instance from the old
>model to the new model (with a new nsURI) on the fly..

That would mean, that I do not generate code for the old ecore, correct? Then I would need to map the content via some reflection mechanism to my actual classes? This sounds quite complicated.

One approach that worked for me is to simply pre/post process my XML Files with a DOM parser to remove/add the required namespace. Not very pretty, but does the job as far as I can see.

Report message to a moderator

Re: Ecore Inheritance in the same Namespace [message #1818791 is a reply to message #1818784]

Sat, 28 December 2019 12:29

Robert Schulk

Messages: 68
Registered: July 2015

Member

Hi Ed Willink,

>(...) for a flexibility, you will accommodate your next ten such requirements. In
>particular identify what is absolutely guaranteed not to change and factor that out as
>a common facility while other things support an appropriate variation point.

That is a valid point. We did exactly that and went quite well so far! Unfortunately, the change now is within the part that should never change :).

>Alternatively if the variations are manageable you can avoid creating 'wrong' objects
> and copying to 'correct' objects by using the XML loader's support for recording
>unknown features so that where possible the 'correct' objects are loaded directly;
>you just have to fix up the obsolete usage from the unknown feature reports.

Thats a cool feature, I did not know about that. Maybe that could be a solution for us as well.

Report message to a moderator

Re: Ecore Inheritance in the same Namespace [message #1818801 is a reply to message #1818791]

Sun, 29 December 2019 10:10

Ed Willink

Messages: 6595
Registered: July 2009

Senior Member

Hi

If you like working at the DOM / XML level, there is now a more disciplined alternative for XML to XML (model) transformations.

The org.eclipse.qvtd.xml plugin of the QVTd project provides an Ecore metamodel for XML. This allows any tool that uses an XMLmodelResourceFactoryImpl rather than generically an XMlResourceFactoryImpl or specifically a MyDslResourceFactoryImpl to exploit a Resource full of EObjects, one per XML element/attribute. Programmatically you can register XMLmodelResourceFactoryImpl as a replacement resource factory for your input file extension. Interactively you may just copy/rename your file to *.xmlmodel and thereafter use any standard EMF tool.

See [1] which also describes the capabilities of the Ecore metamodel for Text in the org.eclipse.qvtd.text plugin.

Regards

Ed Willink

[1] http://www.eclipse.org/mmt/qvt/docs/OCL2018TextM2M/TextM2M.pdf

Report message to a moderator

Previous Topic:	Fail to get inherited EAttribute with Resource.getObject(String uriFragment)
Next Topic:	EMF.Edit-based validation leads to UI freeze

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Sat Feb 29 04:53:51 GMT 2020

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter