< To: AMMA
- KM3 (Kernel Meta Meta Model) is a neutral language to write metamodels and to define Domain Specific Languages
- KM3 has been defined at INRIA.
- There is an evolutive library of metamodels written in KM3.
- This library of open source metamodels may be found at: AtlanticZoo. The contribution to this zoo is open and welcome ;-). Please take a look to the following page: "How to contribute to the Atlantic zoo" if you want to participate.
- This library contains about 180 KM3 metamodels and has been named a Zoo.
- This collection of KM3 metamodels is intended for experimental purposes.
- On the same site there are also a number of "mirror zoos" containing metamodels written in other languages like MOF, UML, Prolog, VB, etc.
- Why genmodel gives me errors when I use Ecore model got from KM3-to-Ecore transformation ?
Because generated Ecore model has no nsURI, nsPrefix attributes setted for packages and no instanceClassName for datatypes.
KM3 is supposed to be a *kernel* metametamodel. That's why there is no EMF-Specific feature like, for instance, nsURI in packages.
Now, concerning the KM3-to-Ecore transformation nsUri, nsPrefix and instanceClassName things could have been hard-coded in it by some kinds of default values. We don't think it is a good solution: it is not configurable and not very beautiful (i.e. not generic regarding other KM3-to-XXX transformation where XXX is a metametamodel such as MDR).
The best one should be to do an ATL transformation taking the Ecore model from KM3-to-Ecore. This transformation copies the model while adding default values to nsURI, nsPrefix and instanceClassName attribute. This is not a very complicated transformation. Thus, you will be able to define your own default value for nsURI, instanceClassName etc.
Another solution is to wait for the next release of KM3 which will provide an model annotation framework and will use it to handle those EMF-specific metadata in a generic way.
KM3: a DSL for Metamodel Specification Jouault, F, and Bézivin, J (2006). In: Proceedings of 8th IFIP International Conference on Formal Methods for Open Object-Based Distributed Systems, LNCS 4037, Bologna, Italy, pages 171-185.