Bridging the MS/DSL Tools
and the Eclipse Modeling Framework
Jean Bézivin, Guillaume Hillairet, Frédéric Jouault, Ivan Kurtev, William Piers
ATLAS Group (INRIA & LINA, University of Nantes){bezivin | g.hillairet | f.jouault | ivan.kurtev | william.piers}@gmail.com
ABSTRACT
Model Driven Engineering is based on a number of principles that
may be applied in different contexts. Nowadays several
environments employ the MDE principles: Model Driven
Architecture (MDA™), Eclipse Modeling Framework (EMF),
Microsoft Domain-Specific Language tools (MS/DSL), and many
more. Focusing only on one context and ignoring otherenvironments and platforms, based on different conventions,standards or protocols would be unwise because one of thedesired properties of models is their ability to be exchanged
between different contexts. Due to their abstraction expression
level, models should ideally be more adaptable to various
operational environments than conventional code. In other words,
OMG models and Microsoft models among others should be able
to be exchanged between the corresponding environments. In thispaper we focus on exchange of models created in these two majorindustrial platforms: EMF and Microsoft DSL. The capability to
exchange models between an EMF and a corresponding MS/DSL
based system requires an abstract understanding of botharchitectures and a precise organization of the interoperability
scheme. This paper describes the first results of a project in thisarea and presents the lessons learnt in this work.

General Terms
Design, Languages.

Keywords
MDE, EMF, MS DSL, ATL, model transformations, technicalspaces.

1. INTRODUCTION
In November 2000 the OMG proposed a new approach tointeroperability named MDA™ (Model-Driven Architecture)[13]. MDA is one realization of the broader vision of Model
Driven Engineering (MDE) that encompasses current research
trends related to generative and transformational techniques insoftware engineering, system engineering, and data engineering.
Considering models as first class entities and any software artifact
as a model or as a model element is one of the basic principles of
MDE. The key ideas of MDE are germane to other approaches
such as domain-specific languages (DSLs), software factories,
model-integrated computing (MIC), model-driven softwaredevelopment (MDSD), model management, language-oriented
programming [3], and many more.

Figure 1 MDE principles, standards and tools.

The OMG MDA initial proposal implements the principles of
MDE around a set of OMG standards such as MOF, XMI, OCL,
UML, CWM, and SPEM. Based on similar principles but
sometimes on different standards (Figure 1), several other related
technical spaces [9] have also been proposed like Microsoft
Software Factories Tools (MS/DSL) [6], Generic Modeling
Environment (GME) [14], Coral [12] and many others.
These spaces are not isolated from each other and should beallowed to communicate by exchanging artifacts. In this paper wewill focus on two of those spaces and the possible links between
them: MS/DSL and Eclipse Modeling Framework (EMF). The
concept of bridge is used to denote the capability ofcommunication between two spaces. If a bridge is available
between spaces then it is possible to import an artifact from one
space to the other and vice-versa.
To implement a bridge between MS/DSL and EMF we use thefunctionalities provided by the AMMA (ATLAS ModelManagement Architecture) model engineering platform. AMMA
is built on top of the Eclipse Modeling Framework and consists offour different components. The component that plays the mostimportant role in the bridge implementation presented in thispaper is a model transformation language named ATL (ATLAS
Transformation Language).
The bridge between MS/DSL and EMF spans two levels:
metamodel and model level. At the level of metamodels it allows
to transform MS/DSL domain models to EMF metamodels. At thelevel of models the bridge allows transforming MS/DSL models
conforming to domain models to EMF models conforming to
EMF metamodels. At both levels the bridge operates in both
directions. A chain of ATL-based transformations is used to
implement the bridge at these two levels. The benefit of using
such a bridge is the ability to transpose MS/DSL work in EMF
platform, and vice-versa.
While pursuing this objective we realized the need of systematic
methods to build bridges between similar or different technicalspaces. The lessons learnt in the realization of the bridge between
EMF and MS/DSL environments are very helpful in building ofother exchange schemes between similar platforms, for example
between GME and EMF.
This paper is organized as follows. In section 2 we describe theplatforms used in this work: MS/DSL, EMF and AMMA. Section
3 presents the metametamodels of these platforms and the basic
functionality of the bridge. Section 4 explains the operation of thebridge at the metamodel level, and Section 5 shows the operation
at the model level. Section 6 concludes the paper.

2. EMF, MS/DSL and the AMMA Platform
The two main industrial references of MDE are currently EMF
and MS/DSL Tools. AMMA extends the EMF facilities in a
number of ways. By design AMMA integrates the notion oftechnical space, i.e. the possibility to interoperate with other MDE
and non-MDE environments. This section provides a brief
introduction to EMF, MS/DSL Tools and AMMA.

2.2 MS/DSL
The Microsoft Tools for Domain-Specific Languages is a suite oftools for creating, editing, visualizing, and using domain-specificdata for automating the enterprise software development process.
These new tools are part of a vision for realizing software
factories [6]. The latest version is May 2005 CTP release for
Visual Studio 2005 Beta 2.
As described in [10], the suite of tools is supported by a code
framework that makes it easier to define domain models and toconstruct a custom graphical designer hosted in Visual Studio.
The suite consists of:-

A project wizard for creating a fully configured solutionin which one can define a domain model that consists ofa designer and a textual artifact generator. Running acompleted solution within Visual Studio opens a test
solution in a separate instance of Visual Studio, allowing
testing the designer and artifact generator.

-

A format and an updated graphical designer for defining
and editing domain models.

-An XML format for creating designer definitions, fromwhich the code for implementing designers is generated.
This allows defining a graphical designer hosted in
Visual Studio without any hand coding.

-A set of code generators, which take a domain model
definition and a designer definition as input, and produce
code that implements both components as output. The
code generators also validate the domain model anddesigner definition and raise errors and warnings
accordingly.

-

A framework for defining template-based artifact
generators, which takes data (models) conforming to adomain model as input, and outputs text based on thetemplate. Parameters in the template are substituted using
the results of running a C# script embedded in thetemplate.

2.1 EMF
EMF is a modeling framework and code generation facility forbuilding tools and applications based on a structured data model.
The following description is adapted from [4]. On the base of amodel specification expressed in XMI, EMF provides tools andruntime support to produce a set of Java classes for the model, a
set of adapter classes that enable viewing and command-based
editing of the model, and a basic editor. Models can be specified
using annotated Java, XML documents, or modeling tools like
Rational Rose, and then imported into EMF. An important featureof EMF is that it provides the foundation for interoperability withother EMF-based tools and applications. EMF consists of threefundamental parts:-

EMF - The core EMF framework includes a metamodel(Ecore) for describing models and runtime support forthe models including change notification, persistence
support with default XMI serialization, and a very
efficient reflective API for manipulating EMF objects
generically.

-

EMF.Edit - The EMF.Edit framework includes genericreusable classes for building editors for EMF models.

-

EMF.Codegen - The EMF code generation facility iscapable of generating everything needed to build acomplete editor for an EMF model. It includes a GUI
from which generation options can be specified, andgenerators can be invoked. The generation facility
leverages the JDT (Java Development Tooling)
component of Eclipse.

2.3 AMMA
Currently built on top of EMF, AMMA [2] brings additional
functionalities and could be implemented on top of other MDE
environments. AMMA has both local and distributed
implementations and is based on four blocks providing a set ofmodel processing facilities:-

Model - provides Java interfaces and implementation
classes for all the classes in the model, plus a factory andpackage (meta data) implementation class.

Atlas Transformation Language (ATL) [1][8]defines
model transformation facilities for a QVT-like language:a transformation virtual machine, a metamodel based
compiler, an editor based on Eclipse, and a debugging
environment.

-

Adapters - generates implementation classes (called
ItemProviders) that adapt the model classes for editing
and display.

Atlas ModelWeaver (AMW) makes it possible toestablish links between the elements of two (or more)different models.

-Atlas MegaModel Management (AM3) defines the way
the metadata is managed in AMMA (registry on themodels, metamodels, and tools).

-

Atlas Technical Projectors (ATP) defines a set of
injectors/extractors enabling to import/export models

Three levels of code generation are supported:---

Editor - produces a properly structured editor that
conforms to the recommended style for Eclipse EMF
model editors and serves as a point from which to startcustomizing.

from/to foreign technical spaces (for instance Javaclasses, relational models).

Metamodel

2.4 Global overview of bridging

1**

Before explaining the implementation of the bridge between
MS/DSL tools and EMF we give the overall idea behind the
project. The bridge performs transformations at two levels: M2
level (metamodel level) and M1 level (model level). Figure 2
provides an overview of the approach.

ModelElement-name : String

EclipseModeling Framework

Package-contents-type

Classifier

Microsoft
DSL Tools-contents

1

1

StructuralFeatures-structuralFeatures-lower : Integer-upper : Integer-isOrdered : Boolean*

M3

Ms/DSLM3 levelmappingEcore-owner

Class

0..1

-opposite-isAbstract : Boolean
1

Attribute

Reference-isContainer : Boolean-supertypes

M2

M1

Domain
model

model

M2 level
bridging

M1 level
bridging

Meta
model

*

*

Figure 3 Simplified version of the KM3 metametamodel

KM3 may thus be used as a pivot between various
metametamodels as illustrated by Figure 4.
model
Ms/DSL

Ecore

Figure 2 Global overview of the two level bridging
KM3

To make a complete bridge between MS/DSL and EMF we must
establish the correspondence between those platforms, at threemetamodeling levels: M3, M2 and M1. The M3 level mapping
allows establishing correspondences between metametamodels.
With these correspondences we can perform the M2 level
bridging that transforms domain models to Ecore metamodels.
The M1 level bridging transforms MS/DSL models to Ecoremodels and vice-versa.

3. M3-level mapping
To enable mapping between MS/DSL and EMF we need adefinition of each system at the M3 (i.e. metametamodel) level.
Microsoft does not specify an explicit metametamodel for DSL
designer, so we had to discover it by observation. The
metametamodel of AMMA platform is called KM3. KM3 is used
as a mediator between the Ecore and the DSL metametamodel. If
we build a mapping between MS/DSL metametamodel and KM3
we can reuse the existing mapping between KM3 and Ecore toobtain the mapping between MS/DSL and Ecore as a compositionof two mappings. KM3 and the MS/DSL metametamodel are
explained in the rest of this section.

3.1 KM3: Kernel MetaMetaModel
KM3 [1], [5] is a metametamodel close to Ecore and EMOF 2.0.
A simplified version is presented in Figure 3. We use it instead of
Ecore because we need to work with several othermetametamodels such as MOF 1.4. KM3 uses a Java-like textual
notation for expressing metamodels. A similar approach is also
proposed by Emfatic [7], a language for representing Eclipse
Modeling Framework Ecore Models in textual forms but the focus
of KM3 is much broader than simply EMF. Of course several
ATL transformations of KM3 notation to or from other notations
are available.

MOF 1.4

Figure 4 Use of KM3 as a pivot

The AMMA platform provides mappings between KM3 and othermetametamodels. This enables easy mapping of a newly added
metametamodel to the existing ones.

3.2 DSL metametamodel
The equivalent of a metamodel in the Microsoft world is called a“domain model”. It is composed of a class hierarchy andrelationships. From our initial experience with Microsoft’s tools
we inferred a DSL metametamodel. The result is expressed in
Ecore and is shown in Figure 5.
DomainModel-supertype1-typeClassifier

1

1-valueproperties**-isAbstract : Boolean-sourceRole+min : Integer+max : Integer+isOrdered : Boolean+isPropertyGenerator : Boolean

ValueProperty-rolesClass*
1

Relationship2-relation-isEmbedding : Boolean
Type

1

Figure 5 Simplified version of the DSL metametamodelA relationship may be a simple reference or an embedded relation(similar to composition in UML terms). It has properties and may
have a supertype. A relationship has two roles, but a futureversion of DSL Tools may propose relationships with n roles.

3.3 Comparison between KM3 and DSLWith those diagrams, we can compare KM3 and DSL with eachother. The following observations may be made:-KM3 and DSL Classes are almost equivalent, and havethe same characteristics, except supertypes: KM3 allows
multiple inheritance whereas DSL does not.

-A KM3 Attribute is equivalent to a DSL ValueProperty.

-

DSL roles can be mapped to KM3 References, but thelatter are not affiliated with a Relationship like in DSL.
References are contained in their owner and linked totheir opposite reference. If the owning relationship of apair of roles is embedded then one of the associated
KM3 references is a container.

--

DSL Relationships and DSL Classes have the same
properties: relationships may be linked to each other,have a supertype and attributes. There is no direct
equivalent of DSL Relationship in KM3. We canconsider simple relationships (with no supertype or
attribute) as corresponding to a pair of references while
complex relationships correspond to classes.
On the basis of this analysis we can establish mappings
between DSL and KM3. Mappings are used to perform
M2-level bridging and are operationalized in ATL
language.

4. M2-level bridging
After establishing the mappings between DSL and KM3, we canuse ATL to transform domain models into KM3 models and into
EMF metamodels with an additional transformation from KM3 toEcore. A detailed overview of the M2-level bridge is given in
Figure 6.
Microsoft
DSL Tools

Eclipse EMF
C2 : conforms to

M3
DSL
C2

M2

C2

C2

C2

Domain
model
MMa

XML

DSL

KM3

C2

C2

C2

C2

DSL
Model

MMa

XML2DSL

M1

Ecore

C2

DSL2KM3MMa
DSL2XMLMMa

Promotion
KM32Ecore

we can apply a chain of ATL transformations to implement the
M2 level bridge. However, first we have to obtain a representationof a DSL domain model as an Ecore model.
The transformation chain for the first direction of the bridge
contains four steps. First, a domain model MMa (defined in DSL
Tools) is transformed to an XML representation conforming to the
XML metamodel. After that, the model is transformed using ATL
to conform to DSL metametamodel expressed in Ecore, and thento a model conforming to KM3. The final step is the promotion ofthis model using KM32Ecore transformation, which creates the
MMa EMF metamodel conforming to Ecore. This operation iscalled promotion since the result lies at a higher level in themetamodeling hierarchy compared to its source. The inverse
transformations from Ecore to DSL are also defined.
In fact we build two transformation chains: from DSL to KM3
and from KM3 to DSL. Since KM3 acts as a pivot between our
metametamodels we already have the transformations to and from
Ecore. The following subsections explain in detail thesetransformation chains.

4.1 First transformation chain: DSL to Ecore
To make the transformation we proceed in three steps. They aredetailed below.

4.1.1 First step: XML2DSL
We have to get information from a .dsldm file into a DSL
metamodel. We inject the .dsldm file into an XMI file conforming
to an XML metamodel, using an XML injector. An ATL
transformation is then applied to capture information from theXML file to a model which conforms to the DSL metametamodel
previously described.
The main work of this transformation is a mapping between.dsldm features (concepts, relationships, roles, enumerations,
properties, etc.) and our DSL model.

4.1.2 Second step: DSL2KM3
In this step we transform the DSL model to a KM3 metamodel,using another ATL transformation. By splitting the transformationfrom XML to KM3 in two steps we first reduce the complexity ofthe transformation and second, we achieve a reusability of thetransformation from XML to DSL and vice-versa.
In the DSL2KM3 transformation, DSL classes are mapped to
KM3 classes, like simple types and properties. We encountered
several problems due to the differences between DSL and KM3
metamodels explained in section 3.3:-

In DSL, a Relationship is defined like a Class, with thesame properties.

-

In KM3, a Relationship between two Classes is encodedby two references into adjoining classes.

MMa
KM32DSL

Ecore2KM3
Demotion

Figure 6 M2-level bridge overview

We have already shown the DSL metametamodel expressed in
Ecore. KM3 may also be expressed as an Ecore metamodel. The
ATL language is capable of specifying transformations on Ecoremodels conforming to Ecore metamodels. Therefore we cantransform DSL domain models into KM3 models. KM3 models
may be transformed into Ecore metamodels (recall that there exist
a reusable transformation between KM3 and Ecore). In summary,

We found two solutions to this problem:
Solution 1: We can ignore all specific properties of theRelationship except roles and type of containment.
Solution 2: We can turn the Relationship into a KM3 class, andkeep the attributes, supertypes, and other features.

In both cases some information is lost. In solution 1 we loose
Relationship features. In solution 2 we loose track of the fact thatthe source element is a Relationship. Transformation of theresulting KM3 metamodel back into a DSL metamodel produces a
DSL metamodel, which contains less information than the originalone. We may cope with this issue by keeping the information thatcannot be represented in KM3 into an additional model. This
information would then be used by an enhanced version of
KM32DSL.
To apply our solutions, we can classify DSL Relationships in two
types:-

4.2.2 Second step: DSL2XML
We transform the result from the previous step into a model
conforming to XML, which defines a .dsldm like file. Figure 8
shows a simple metamodel of .dsldm file. The gray boxes showwhat is added from scratch when we make the transformation andthe white ones show what is supported by our DSL
metametamodel.

Simple Relationship:

extended *If a relationship does not have any supertype or attribute then we
can ignore the name and transform the relationship into a couple
of KM3 references. Using solution 1 the roles of a relation are
mapped to KM3 references.
-

Some attributes of DSL don’t have correspondence in KM3, so
we create them using default values, and we generate single
identities.

DMD-xmlns:xsi:String-xmlns:xsd:String-xmlns:String

Model
models1..*-name:String-identity:String-id:String-namespace:String-isLoaded:Boolean

Complex Relationship:
mdfmetadata

If the relationship has attributes, supertypes, or subtypes, we turnit into a KM3 class (using solution 2), and we create two pairs ofreferences to link it to the classes referenced by its roles, like in
Figure 7.

Modelmdfmetadata* enumerations

Enumeration* concepts

Concept* relationships

Relationship* trees

TreeNavigator-majorversion:integer-minorversion:integer-localize:Boolean

Figure 8 Simple metamodel of .dsldm file

We use an ATL transformation, which creates an XML model
similar to a .dsldm file.

sourcetype

To be able to build diagrams as trees, DSL Tools needs to satisfy
some constraints which are specified in the tree navigators. For
instance we must signal if a class needs to appear several times, orif a class needs to be considered as a root class (if it must appear
on the left side of the diagram).

4.2.3 Third step: XML2Text
Figure 7 An example of Complex Relationship treatment

4.1.3 Third step: KM32Ecore
Using the existing transformation KM32Ecore, we get ametamodel conforming to EMF. We can now use this model
within any EMF compatible tool, for example, Omondo’s
EclipseUML plug-in. With this last step the first direction of theM2-level bridge is completed.

4.2 Second transformation chain: Ecore to
DSL
We start this transformation with a model which conforms to
KM3, and want to transpose it into a DSL tools model. To achieve
the transformation we proceed in three steps detailed below.

4.2.1 First step: KM32DSL
When we transform our initial model (which is expressed inKM3) into a model which conforms to our DSL metamodel, we
find problems similar to the one explained in section 4.1.2.
KM3 doesn’t implement Relationships, so we have to create themfrom pairs of KM3 References.

We use existing XML to text transformation to create a .dsldm filethat will be included into a "blank project" for DSL Tools, by
replacing the .dsldm file.

5. M1-level bridging
M1 level bridge allows transforming DSL models to and from
EMF models. We describe such a tool in this section.
First we have to know how models are viewed by the twotechnologies. Basically a model has to conform to a domain
model in context of MS/DSL and to an Ecore metamodel for
EMF.
To store models, Microsoft uses XML documents that conform to
an XML schema, which does not directly map to the domain
model. With EMF, the models are stored in XMI format andexplicitly conform to a metamodel.
To implement the M1-level bridge we have to transform a DSL
model file to a model that conforms to a metamodel defined under
EMF. To do this we have to make a metamodel for the DSL
models.
The problem is that if we write a transformation between the DSL
metamodel and the metamodel in EMF, we’ll have to write atransformation per EMF metamodel. This approach is not general.
We need a transformation that works for any EMF metamodel.
How this is done is explained below in section 5.4.

We will use ATL as in the M2-level bridge. The process will be
performed in three steps, as shown in Figure 9. For simplicity weonly describe the transformation chain from DSL to EMF:-

The first step consists of injecting the DSL model file Ma
to an XML model.

-

In the second step we transform the XML model into amodel conforming to the DSL models metamodel (named
DSLModel in Figure 9). DSLModel was defined tomatch Microsoft’s schema as closely as possible.

-

In the third step we apply an ATL transformation thattakes as input a DSL model Ma and the metamodel MMa
defined under EMF and output a model Ma that
conforms to the model MMa.
Microsoft
DSL Tools

M3

Eclipse EMF
C2 : conforms to

DSL

5.2 First step: Inject XML file to XML model
The first step injects the XML file containing the DSL model
definition into an XML model that conforms to the XML
metamodel.

5.3 Second step: XML2DSLModel
The second step transforms the XML model to a model that
conforms to DSLModel. We use an ATL transformation to do it(XML2DSLModel in Figure 9).

5.4 Third step: DSLModel2EMFModel
The last step has to produce a model conforming to its EMFmetamodel. This metamodel varies so if we write a transformation
between DSLModel and the metamodel it will work for only one
concrete EMF metamodel. To obtain a generic transformation
definition that works for every target metamodel we proceed in
two steps shown in Figure 11.

Ecore
C2

C2

C2

M2

DSLModel

C2

C2

M2

Domain
model
MMa

XML

C2

C2

DSL
Model
Ma

XML
model
Ma

MMa

DSLModel

C2

ATL
M1

Ma

EMFModel2DSLModel

Figure 9 M1-level bridging overview

5.1 The DSL models metamodel
We created a metamodel close to the schema used by Microsoft tostore DSL models as XML files. This metamodel is called
DSLModel and is shown in Figure 10.
Model

Element+id : int
+type : string-contents-elements
ModelElement

ReferenceLink

1
*
1

*

*

EmbeddingLink*-element

1+properties

2

1

Property

EMF Model
Ma

Figure 11. Overview of Step 3

The first step is to apply an ATL transformation (Generate ATL
model in Figure 11) that takes as input an EMF metamodel andgenerates an ATL transformation (DSLModel to EMFModel in
Figure 11). The generated transformation contains the necessary
rules to produce a model conforming to the EMF metamodel. Thissolution is generic and works for any EMF metamodel. The
second step is to apply the generated transformation in order toobtain an EMF model Ma from the DSL model Ma.
In the first step we use the fact that transformation definitions arealso models and therefore may be generated by a transformation.
In other words we create a higher-order transformation to solve
the problem with the generality of our solution.

6. Conclusions

1

1

DSLModelto
EMFModelDSLModel2EMFModel

DSL
model
Ma

In the remaining part of this section we give details on the DSL
models metamodel and the three steps outlined above.

*

DSL Model
Ma

C2

DSLModel2XML

1

EMF
metamodel

Generate
ATL model
outputXML2DSLModel

M1

input

ATL

-role

+rolesRole

1

Figure 10 The metamodel DSLModelIn this metamodel the attribute type of class Element contains thename of the class from the domain model that is instantiated in themodel. A model element has properties that correspond to
attributes in domain model, a reference link is a reference
relationship and an embedding link is an embedded relationship.

This paper has reported on an experiment of practical interest:building operational bridges between two industrial MDE
platforms: MS/DSL tools and EMF. Since EMF is often
considered as one of the major implementations of OMG
standards, the resulting tools are of high potential utility to makethe MS world and the OMG world communicate in the domain ofmodel engineering.
We have seen that achieving model interoperability is much more
complex than simply defining a local serialization format in a
local context like XMI.
However the value of this work goes much beyond merepracticality. It shows that different kinds of models may beexchanged between different technical spaces. It suggests a
general way to building bridges between different spaces.
Knowing the rising fragmentation in current technologies, thisissue will probably become increasingly important in the future.

Interoperability is a horizon that moves farther and farther as one
tries to come closer. The conviction that there will never be aunique operating system, a unique programming language, aunique database management system or a unique network
framework has convinced organization like OMG to consider
heterogeneity as inherent to IT and to pursue interoperability as amain goal. The limits of code-based or middleware-based
interoperability have been reached with proposals such as
CORBA and IDL to hide operating system or programming
language heterogeneity in distributed applications. The existenceof several de-facto middleware-like frameworks is now a reality.
Model-based interoperability is trying to approach the problem ata higher abstraction level.
Using one unique and rathermonolithic language like UML 2.0 is not very realistic. Instead
the solution is to use a metalanguage building system like MOF,
allowing defining a set of domain-specific languages throughmetamodels like UML, SPEM, CWM, EDOC. This seemed to be
the current state of the art in model engineering until recently.
Unfortunately the situation is no more so clear and the MOFbased metamodel building system proposed by OMG willprobably face several new competitors. Some of them like EMF
are really close but other are making quite different assumptions
on what should be in a metametamodel. Similarly to CORBA that
had to cope with different middleware proposals, MOF, XMI and
OCL may also have to cope with different other metamodelingproposals, sometimes with apparent advantages. The present work
addresses at the same time some conceptual and practical issues
raised by this situation.
The naive answer to this situation could be to build an additional
M4 metamodeling layer, but obviously this is not a serious
suggestion. Instead we have to prepare a systematic and methodic
bridging approach between different representation systems (suchas MOF, MS/DSL, XML, EBNF). This is possible because thenumber of such technical spaces (based on trees, graphs, or othersimple algebraic structures) is limited and by considering all thesespaces as having a three-level organization (M1, M2, M3), it ispossible to keep this diversity of technical space representation
under control.
The only alternative to this solution would be to wait that one
technical space prevails on the other ones by making themobsolete. By experience and observation we know that this will
never happen. We thus propose to improve bridging schemes suchas the one presented in this paper and to hide as much as possible
their implementation complexity to the end-users. When a user
will be allowed to work indifferently with an XML-schema, an
EBNF-grammar, a MOF-metamodel or a MS/DSL Domain
Model, and when the differences in representation will be madetransparent, he/she may be able to work on solving the real
problems and not curing the artificial problems introduced byincreasingly fragmented and complex technology.

7. Acknowledgements
We would like to thank Freddy Allilaire, David Touzet, Patrick
Valduriez and all the members of the AMMA group for theirnumerous contributions to this document. This work has been
supported in part by the IST European project "ModelWare"contract 511731) and by a grant from Microsoft Research(Cambridge).

8. References[1] ATL, ATLAS Transformation Language Reference site
http://www.sciences.univ-nantes.fr/lina/atl/ including KM3:
Kernel Metametamodel definition.
[2] Bézivin, J, Jouault, F, and Touzet, D: Principles, Standards
and Tools for Model Engineering. In: Proceedings of theUsing metamodels to support MDD Workshop, 10th IEEE
International Conference on Engineering of Complex
Computer Systems (ICECCS 2005). See also research report
http://www.sciences.univ-nantes.fr/lina/atl/www/papers/RRLINA2005-01.pdf. http://www.sciences.univnantes.fr/lina/atl/publications/ http:/www.sciences.univnantes.fr/lina/atl/www/papers/AMMA_ICECCS05.pdf[3] Dmitriev, S. Language Oriented Programming: The Next
Programming Paradigm, OnBoard, november 2004,
http://www.onboard.jetbrains.com/is1/articles/04/10/lop/mps.pdf[4] Eclipse Modeling Framework http://www.eclipse.org/emf/[5] GMT, General Model Transformer Eclipse Project,
http://www.eclipse.org/gmt/ including KM3: Kernel
MetaMetaModel definition.
[6] Greenfield, J., Short, K., Cook, S., Kent, S., Software
Factories, Wiley, ISBN 0-471-20284-3, 2004.
[7] IBM Emfatic Language for EMF Development AlphaWorks,
http://www.alphaworks.ibm.com/tech/emfatic[8] Jouault, F., and Kurtev, I., Transforming Models with ATL,
to appear in proceedings of Model Transformations inPractice Workshop, October 3rd 2005, part of the MoDELS
2005 Conference[9] Kurtev, I., Bézivin, J., Aksit, M. Technical Spaces: An Initial
Appraisal. CoopIS, DOA’2002 Federated Conferences,
Industrial track, Irvine, 2002 http://www.sciences.univnantes.fr/lina/atl/publications/[10] Microsoft Domain-Specific Language (DSL) Tools, May
2005 CTP Release for Visual Studio 2005 Beta 2.
http://lab.msdn.microsoft.com/teamsystem/workshop/dsltools/default.aspx[11] MS/DSL Tools Walkthrough 1 downloadable fromhttp://lab.msdn.microsoft.com/teamsystem/workshop/dsltools/default.aspx[12] Porres, I. The CORAL Platform.
http://mde.abo.fi/tools/Coral/[13] Soley, R., and the OMG staff, Model-Driven Architecture,
OMG Document, November 2000, http://www.omg.org/mda[14] Vanderbilt Institute for Software Integrated Systems (ISIS)
Web-based Open Tool Integration Framework (WOTIF)
http://www.isis.vanderbilt.edu/Projects/WOTIF/default.html