Questions and Answers – "M" Modeling Language

[This content is no longer valid. For the latest information on "M", "Quadrant", SQL Server Modeling Services, and the Repository, see the Model Citizen blog**.]****


Q. What is “M”? Why are you building it?

A. “M” is a new declarative language that provides developers with an approachable, textual format for authoring models and domain-specific languages (DSLs) for those models. The “M” language allows specification of structural types, values (storing and queries), and domain-specific languages (token and syntax rules), all of which enable the developer and third-party ecosystem to have a natural development experience for building models.

“M” is being developed as a complement to visual modeling tools so that developers can choose the format (text or diagrams) that are best suited for their task and their experience.


Q. What role does “M” play in Microsoft’s language portfolio?

A. “M” is a pragmatic tool to accomplish a specific job and includes concepts that we hope will facilitate authoring models. Specifically, making constraints first class is not unheard of, but is unusual. Also, the simplicity of the underlying data model is rare.


Q. Will the “M” language be standardized?

A. We are making the “M” language specification available under the Microsoft’s Open Specification Promise (OSP) so third parties, including open source projects, can build implementations of “M” for other runtimes, services, applications, and operating systems. Interested parties are also encouraged to join the “M” Specification Community to participate in the ongoing evolution of the “M” language specification.

A. We are making the “M” language specification available under the OSP so third parties, including open source projects, can build implementations of “M” for other runtimes, services, applications, and operating systems.


Q. What is the “M” Specification Community?

A. The “M” Specification Community is an online discussion group that will be used to gather feedback on the “M” specification during its development and represents our approach to enabling the broadest set of contributors to provide input to the development of “M”. We are interested in working with the industry to generalize an approach to model-driven programming and develop a consistent approach needed to make this a mainstream application development activity. We believe it is very important that the efforts to form the specification are done jointly with members across the community and reflect priorities/input that is both cross-platform and cross-language (much as we helped establish feedback within the XML and Web services arena, and our participation with industry leaders as part of the Web Services Interoperability Organization, WS-I).


Q. How does the “M” Specification Community discussion group work?

A. Interested parties may join the “M” Specification Community by going to and agreeing to “M” Specification Participation Agreement. This agreement states that you agree to allow Microsoft to release the spec, including your accepted contributions, under Microsoft’s Open Specification Promise (OSP). The OSP provides assurances to individuals and organizations wishing to create or use an implementation of the “M” spec that they may comfortably do so under relevant Microsoft patents. Once you have accepted the participation agreement, you can participate in the development of the spec by using the “M” Specification Community mailing list. If you do not choose to accept the agreement, you can still monitor the development of the spec on the mailing list, as it is public.


Q. What opportunities does the “M” Specification Community present for partners and community members?

A. Customers and partners have the ability to influence Microsoft’s direction with “M” by providing early feedback and gain early insight and education into Microsoft’s approach to developing “M” and the SQL Server Modeling CTP technologies in general. This level of participation will also help our partners get ready to take advantage of new business opportunities with the SQL Server Modeling CTP at an earlier stage.

Microsoft always appreciates the feedback and partnership it has with the community in these early development stages, and regards the feedback with utmost importance.


Q. Will it be both technically and legally possible for a third party to build an implementation of “M” on another database and operating system?

A. Absolutely. This is the reason why we are releasing the specification under the Open Specification Promise.


Q. What happened to MSchema, MGraph, and MGrammar?

A. In the past, different parts of the overall “M” language were being developed in separate specifications. Since then those specifications have merged into a single entity, the “M” Language Specification, so it’s no longer necessary to use these terms. At present, we speak of “M” types, values, and languages instead.

Q. When does a developer use “M” vs. T-SQL? Should I use “M” rather than T-SQL to define the shape of my data?

A. Today, “M” is not yet a shipping product, so customers should definitely use T-SQL for their mission critical applications. Once “M” ships, the goal is to use “M” to describe a problem domain in a higher-level of abstraction. Then, “M” can be translated into T-SQL, C# or other formats, enabling further optimizations in the native target runtime.


Q. How do I migrate my legacy T-SQL to “M”?

A. First, T-SQL is not legacy. We love T-SQL. The “M” tools have the "export" feature to produce “M” from an existing database. We only support export for those T-SQL concepts that are naturally represented in “M” such as Tables, Views, and Functions. In this way, you can think of “M” as the Visual Basic of data modeling, enabling a simpler way to read and write down the shapes of your data, whereas T-SQL will always be the C++, giving you access to the full power of the platform.


Q. Will Microsoft expose the mapping of “M” to the SQL language used with SQL Server?

A. Yes. The mapping between “M” and SQL Server is an appendix of the language specification that we are releasing under the Open Specification Promise.


Q. Will Microsoft expose the SQL schema used by “M” and how these schemas are used to reflect models defined in “M”?

A. Yes. The mapping from “M” to SQL Server is an appendix of the language specification that we are releasing under the Open Specification Promise.


Q. How does this work relate to C# and Visual Basic?

A. C# and VB are our premier general-purpose programming languages for the .NET platform. While the SQL Server Modeling CTP offers languages in the form of textual DSLs focused on model-driven runtimes, applications, and services, this does not diminish C# or VB in any way. In fact, most model-driven runtimes are written using C# and VB. As such, these general -purpose languages and DSLs written in “M” are very complementary and we expect developers to leverage the power and expressiveness of both.


Q. Why not model my data in ERwin?

A. ERwin (a visual data modeling tool from Computer Associates) and Microsoft Visual Studio are great tools that make it easier to write T-SQL but do not fundamentally raise the abstraction of programming. Also, as with the other graphical input formats, neither provide an easy way to define either complex constraints or instance data.


Q. Is there “M” support in Visual Studio? (I do all of my C# and T-SQL there today, so I expect “M” support as well.)

A. Yes, “M” can be directly incorporated into a Visual Studio project like files of any other language.


Q. How do “M” and .NET interoperate?  For example, how does “M” interoperate with SQLCLR?

A. “M” is built as a .NET framework that can be leveraged in your .NET application code.

Q. Is “M” a general solution for creating external domain-specific languages (DSLs)?

A. Yes, “M” has the facilities to write DSLs.

Q. How does the DSL support of “M” relate to the “internal DSL” approach that C# and VB are using with PLINQ, TPL, Code Contracts, etc.?

A. “M” provides features to process text and produce structure values. Those structure values can then be used by the “M” tools produce SQL or other representations. Those values can also be consumed using the “M” .NET framework library to programmatically construct other representations as desired.

Q. Is Microsoft going to use “M” for future versions of XAML, ASP.NET, etc., that combine data/markup and behavior/code?

A. There are currently no plans to use “M” as a representation in addition to or instead of XAML and other dialects of XML.

Q. What is the relationship between the DSL Toolkit and “M” for building Domain Specific Languages?

A. The DSL Toolkit is a framework and set of tools for building visual DSLs inside of Visual Studio. One of the things that the “M” language provides for is the ability to create text-based DSLs. Both have their place in the world depending on your goals and your audience. **

Q. What is the future of the DSL Toolkit? Does it still exist?

A. The DSL Toolkit will continue to ship on top of the Visual Studio SDK in 2010.  In fact, the Visual Studio UML tools are built utilizing the DSL Toolkit.

Q. Why is "module" used instead of "namespace"?

A. Modules do control visibility as namespaces do. However, unlike namespaces, modules do other things such as allocate storage. We also considered "schema" instead of "module" but, like "namespace", modules support more than just schema definition, such as domain-specific languages.


Q. It seems there isn’t a way to model many-to-many relationships directly. Instead, they have to be modeled as two one-to-many relationships. Is this true?

A. There are lots of different kinds of relationships. Even with something as straightforward as "one-to-many" there are several options: mandatory one-to-many, optional one-to-many, one-to-many with containment, etc. Consequently, there are varying degrees of integrity enforced on relationships and, notably, no pervasive agreement on the meaning of these relationships. Rather than bake in an arbitrary interpretation of relationship support, we ensured that “M” includes the building blocks that enable modelers to build up exactly what they want. The down side is that modelers have to build up exactly what they want.


Q. Why doesn't “M” have inheritance?

A. A lot of people ask for inheritance. “M” does not have inheritance because the relational data model does not have inheritance. The alignment with the EDM requires the ability to model inheritance, so we are considering ways to do this in “M”.


Q. How do I declare an index?

A. You cannot declare an index in “M” today but we’re evaluating that feature for future versions.


Q. How do I say an entity is contained?

A. Today, there is no way to model the notion of containment in “M” as described in other models such as UML. We are looking seriously at the requirements to represent containment and working towards a solution that fits naturally with “M” principles and data model.


Q. How do I declare cascading delete?

A. This is an operational aspect that “M” does not address. We are considering the requirements for modeling behavior such as cascading delete in “M” as we continue to look at additional features needed by the language. In the mean time, you can build the SQL statements to augment the generated SQL to add support for cascading delete to your “M” extents.


Q. Can I have recursive models (e.g. parts of parts)?

A. Yes. “M” fully supports recursive models and the recursive queries needed to access them.


Q. Can I write stored procedures in “M”?

A. Speaking of stored procedures in the context of “M” is speaking on the wrong level of abstraction. Stored procedures are a SQL construct and so certain “M” constructs (namely functions) naturally manifest as stored procedures. However, that’s simply a manifestation of the mapping of “M” to SQL, as the “M” language in itself doesn’t directly provide for that level of definition or common associated features such as cursors, control flow, and local variables. “M” does allow you to define functions, however, and those map to SQL stored procedures, views, table-valued functions as appropriate.**