0. Index

  1. Introduction
  2. Platform
    1. M
      1. Mgrammar (Mg)
      2. Mschema (Ms)
      3. Mgraph (Mg’)
    2. Quadrant
    3. Repository
  3. Addendum 1
  4. Addendum 2

1. Introduction

I’ve been watching quite a few Microsoft PDC 2008 presentations and slides as of late and perhaps thé technology to see at PDC 2008 was the new Microsoft “Oslo” modelling platform. It is Microsofts attempt to put modelling at the forefront.

I recommend the PDC 2008 “Oslo” presentations before this post, in particular the M presentation. References at the end of this post.

Model-Driven Development  (MDD) and other subspecies are by no means new but when Microsoft takes on this discipline in such a major and orchestrated way, it is going to have an impact, in a major way. It will impact Microsoft internally, meaning they will begin to dogfood this technology in all sorts of ways – they will make their own applications take advantage of modelling and the repository.

In some cases the model may be the application, in the sense that it is an executable specification, itself subject to data transformation – imagine a workflow represented as a model, for example.

So what does it include? So far my overview of the “Oslo” platform has

  1. M
  2. Quadrant
  3. Repository

2. Platform

2.1. M

M is the modelling language. So we can split that up somewhat

  1. Mgrammar
  2. Mschema
  3. Mgraph

2.1.1. Mgrammar (Mg)

So what this is, is first the language metasyntax, Mgrammar – think of it as a kind of XML; there you can also specify other languages. These languages all have the XML feel, and overhead, which is what makes XML extensible. This is actually not bad, but if you just want to model a language in a very direct way, so that the syntactic “noise” goes away, then you can use MGrammar. It will allow a more natural expression of textual languages than XML will.

2.1.2 Mshema (Ms)

Mschema I don’t know much about except that it appears to be a language for defining dabase schemas at a high-level. It makes it possible to define relationships between types, what properties are identity properties (think keys) and even to express virtual properties that are expressed in terms of functional queries.

2.1.3 Mgraph (Mg’)

Then we have Mgraph. Now this is the simplest part because this is simply an abstract datamodel, just as the XML Information Set (Infoset) is for XML. It is a labelled Directed Acyclic Graph (DAG) which means it is more structurally powerful than the tree-based Infoset model. An Mgraph value is the result of a parse of an M string combined with an Mgrammar (you need the language syntax with its graph projection rules in order to create an MGraph value out of an example text [file]). So this could be, for example a list of contacts in a text file and then the MGrammar file will specify the contact syntax and how it projects into an Mgraph.

So who wants to write grammars in Notepad? Intellipad to the rescue!

Intellipad allows a 3-panel view of

  1. The text
  2. The Mgrammar
  3. The Mgraph

Now of course the Mgraph is also represented as text (it has to be shown somehow, right), but then you see the structural tree view of the parsed Mgraph.

This is actually quite an ingenious little tool because it allows you to directly see if an example conforms to a grammar and what the graph value of that example will be, in real-time. So both the instance and the grammar can be sculpted in a very organic fashion based on actual data.

M is quite a nice way to map microformats into Mgraph values as well. If there is a straight-forward microformat, it may be possible to model its grammar with Mgrammar and have parse and Mgraph construction for free – you (or someone else) only need to define the Mgrammar.

2.2 Quadrant

Quadrant is a visual modelling tool that allows you to interact with stored models. I don’t have much to say about it, except that it appears very cool to work with and gives a very nice intuitive slice of the data. Imagine modelling workflow datamodels visually, composing activities together visually. Or you might want to browse business data and processes, etc. etc. For any domain you can think of. Oh, and buy a very large screen or surface, Quadrant appears ideally suited for ST-sized screens. I’m not sure if Quadrant is built in WPF, but it would make sense if it were. WPF is perfect for rich complex graphics and so it will allow Quadrant to evolve rapidly with new kinds of data controls.

2.3 Repository

Now the repository is, I believe, so far built on SQL Server. Mschema can be used to help shape the database so SQL Server can manage storage of the models effectively. This is also something I can’t say much about. It’s a foundational piece of the whole picture. An important piece but not one I as a developer is as excited about – this is “just” the storage (and where all the cool magic is taking place of course).

3. Addendum 1 – The M | XML Parallel Universe

The M | XML parallel is quite well-defined

  1. Mgrammar | XML
  2. Mschema    | XML Schema
  3. Mgraph        | XML Information Set

In a loose sense you may think of XML Information Set as the abstract model that says what aspects of the XML syntax must be preserved by any valid XML Information Set processor (comformant software). It provides a way to express what aspects of XML are relevant for all applications that claim to be Infoset compatible. Any by proxy what aspects are not relevant.

Both Mgraph and the XML Information Set are abstract syntax specifications. Implementations preserve these structures. Imagine an XML DOM implementation that preserves the XML Information Set aspects of XML documents and vice versa an Mgraph implementation that preserves the aspects of the relevant abstract syntax that an Mgrammar projects into. In both cases M | XML software stack means “end-programmers” will only need to work on the parse structure, meaning e.g. a XML DOM value or a Mgraph value, for example. There’ll be many implementations of an XML DOM (and even streaming models) and the same will probably be true for Mgraph, as the specifications will be fairly open, as far as OSP goes.

XML Schema defines the “macro” and “micro” format of XML – the structural aspects that must be preserved (XML nesting) and the textual aspects, like saying an XML element must contain an integer or an XML attribute must contain a string that conforms to a regular expression that maps phone numbers.

In effect we can think of Mgrammar [, Mschema] as blowing all this to pieces via unification

  1. No more elements vs attributes thinking
  2. No more microformats – all is defined and projected into Mgraphs, no need to have undefined structured strings as we know from the SVG path attribute; this is not a fault of XML itself directly but rather an effect of some implementers wanting compression and a compact way to write path expressions I suppose; well in Mgrammar, you can have both: you can write in a very compact way and still map everything into a rich Mgraph
  3. Graphs instead of trees; in XML one can of course model graphs indirectly, but Mgraph directly understands them, no layered interpretation necessary

I hate Microformats. M means we’ll never have to sacrifice our models to get compact syntax. Praise the Lord!

4. Addendum 2 – Programming languages vs modelling languages.

So how far does the Mgrammar expressiveness go? It turns out that MGrammar is able to model C# (I gather all versions). It is not directly able to model VB. It also turns out that the VB team decided to embed XML in VB a decision that had some hype/geek factor but had some dubious thinking behind it as well. This is now giving a backlash because it is not immediately possible, according to Paul Vick, to model the whole VB grammar in Mgrammar – specifically due to the substantial XML subgrammar of VB. It may become possible in the future. That would be pretty major.

It’ll be interesting to see the hordes of Mgrammars that will pop up for programming languages. C#, F#, subset of VB, etc. – And indeed the new programming languages that will be modelled in Mgrammar – their concrete syntax anyway.

Now, having M, one can think of playing with creating variations of C# with extensions for different domains. A fun little idea. I imagine there will be conventions for language embedding. No conventions or best practices exist, these will emerge.

So that’s it for “Oslo” this time around. I may decide to write more on it later when my hands have dirt on them.



About xosfaere

Software Developer
This entry was posted in Computer Science, Datamodel, Declarative, Infoset, Paradigm, Program, Software, Technical, Uncategorized and tagged , , , , , , , , , . Bookmark the permalink.

One Response to M

  1. Pingback: Development in a Blink » Blog Archive » Microsoft Oslo - MGraph

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s