Skip to main content

Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » Modeling (top-level project) » Is Ecore fit for EMOF meta-modeling?
Is Ecore fit for EMOF meta-modeling? [message #573366] Tue, 06 June 2006 19:04
Ed Willink is currently offline Ed WillinkFriend
Messages: 5930
Registered: July 2009
Senior Member
I have recently encountered some nasty problems when trying to use Ecore as
the underlying technology for QVT and consequently EMOF-based modeling.

The problem is that QVT is based on EMOF and so defined in EMOF and so
at some meta-meta-... level the model must be EMOF.

Ecore is effective as a generator of executable Java models, for which
at some meta-meta-... level the model is Ecore.

Now if QVT is modeled using EMF, it is possible to register QVT as an
Ecore package and to have a consistent model that uses EMOF. However a QVT
transformation applied to a QVT model must be able to access the QVT meta-model,
and that meta-model is Ecore not EMOF, so unless EMF provides an ability to
access (rather than just serialise) a registered Ecore model as EMOF, it is not possible
to traverse the meta-levels of QVT without crossing from EMOF to Ecore and
getting type violations.

We seem to have 2 choices, either every EMOF derived model must acquire a
an E counterpart. We already have (E)OCL, but we will need EQVT etc, etc, etc.

Or we recognise that EMOF-based modeling should be EMOF-based.

The latter means that resolution of the QVT URI must be able to resolve to

A closely related problem that I have observed with OMELET, Tefkat, ATL and
MOFScript, is how to convert a meta-model-name into a model-model-content.

The EMF Package registry provides a partial solution, using a URI as a
meta-model-name, but it only works for meta-models
that have been successfuly converted to Java code. This is not possible for
unmodified EMOF models, since nsURI and instanceClassName nulls cause NPEs in
genmodel, and anyway, why is it necessary to generate Java code when none is wanted?

It seems that the EMF Package registry should have two forms of registration:
URI => implementing Java class, genModel file name
URI => emofModel file name
so that the latter can be consistently used for EMOF-based meta-modelling, and the former
for Java-based executables. The emofModel could be auto-generated by genModel for Java-based

We just need an ability to register emofModels in plugin.xml. To avoid the
inconvenience of starting up nested Eclipse sessions, we need a registered package
browser that supports maintenance and loading of perhaps a .metamodels file per


Ed Willink
Previous Topic:User-defined datatypes
Next Topic:MDA support?
Goto Forum:

Current Time: Sat Jun 23 14:33:48 GMT 2018

Powered by FUDForum. Page generated in 0.02252 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top