DSL Tools, UML and MOF

We’ve received a couple of questions on the DSL Tools Forum which I thought I’d expand upon here.  The questions are:
- Why don’t we use UML to define our metamodels?
- Why don’t we use MOF to define our metamodels?

To answer these effectively, it’s necessary to unpack them, because different people mean different things by these terms.  I think these are the basic questions:
a) Does our tool implement the MOF model?
b) Why don’t we use a UML tool to define our domain models?
c) Why don’t we use UML notation to define our domain models?
d) Can we interchange XMI?

Our Domain Specific Language tools are designed to create editors that are integrated into Visual Studio.  To do this, we have to define many concerns, including abstract syntax, notation, constraints, mappings to files, toolbox behaviour, explorer behaviour, properties browser behaviour, delete behaviour, copy/paste behaviour, rules, transactions, and events: and we do it in managed code, running on the .NET framework and the Visual Studio SDK.  This is the background against which our design decisions must be understood.

(a) The only concern that the MOF model would directly apply to would be the abstract syntax.  In fact our API for manipulating instances of domain classes in the store manipulates exactly the same kind of things as the MOF model defines: classes, properties, and relationships.  We differ from MOF terminologically, in order to be consistent with .NET; but conceptually we are dealing with the same stuff in a .NET context.
(b) A complete UML tool would be too heavyweight a solution for defining domain models.  We’d only use class diagrams, but we’d still have to add many extensions in order to address concerns other than abstract syntax.  Instead, we have built our own lightweight domain-specific tool, which is tailored for the purpose for which it is intended.
(c) One of our design decisions for creating domain models is that they should be completely automatically laid out: we did not want to carry around visual layout information in our domain model files.  To do this, we found it valuable to capitalize on the inherent tree structure of such models, and to design a notation that makes this layout easy.  It takes a little while to get used to this notation, but it does borrow quite heavily from UML e.g. in the way that it represents inheritance and multiplicity.  Decent autolayout of UML diagrams would involve much more complex algorithms, and we didn’t want to put our efforts there at present.
(d) Yes. See Stuart's comments.