'Oslo' & Modelling

Where is Oslo Going?

Charles Young — Mon, 13 Apr 2009 18:27:53 GMT

I've been engaged in some debate in the last few days with Jean-Jacques Dubray and Doug Purdy with regard to Oslo. See:

http://www.ebpml.org/blog/182.htm

http://www.douglaspurdy.com/2009/04/09/where-is-oslo-going-part-ii/

Jean-Jacques has questioned aspects of Microsoft's strategy. Following some issues with posting anything but the shortest of comments on the ebPML web site, I'll follow Doug's lead and post a response here.

I strongly agree with Jean-Jacques' statement that 'M3 exists'. It seems a little strange to feel the need to state this emphatically, but the existence of M3 has sometimes been challenged. Today, 'Oslo' does little to call out or underline the existence of M3. 'Oslo' really isn't expressed in terms of 'classic' metamodel architecture. I would expect this to be unnerving to some people in the MOF community, and my interest, in a previous post, has been to attempt to show that, despite appearances, there is actually an underlying and solid foundation of common ground between OMG specifications and Oslo. There is also a lot of history to this.

It seems to me that multiple metamodel layers exist regardless of technology or specification. However, the degree to which we need to express them within any given context, and the way we choose to do so, is absolutely a matter of pragmatics. I'm schooled in the old linguistic philosophy that languages (including modelling languages) are built on the 'trinity' of syntax, semantics and pragmatics. It is these three areas that Oslo so directly calls out and emphasises. To date, it has, if anything, overly-separated these distinct concerns and I suggest that a lot of the feedback Microsoft has received from the CTP is, in reality, asking them to look for more effective and practical interaction between these different aspects of their emerging technology. These requests are absolutely driven by pragmatic considerations. So, while I appreciate Jean-Jacques' comments about pragmatics, I think that this is potentially the area of greatest strength in terms of what Microsoft is doing. If they get it right (and there is no guarantee of that), they will succeed in providing a set of tools that add real and significant value to their platform and support far more effective use of models in both architecture and development.

In terms of the technology, Oslo offers one language - 'M', founded on graph theory and expressed through MSchema and MGrammar. M is designed to be used at any level within a metamodel architecture. I've always found it difficult to imagine any practical need for M4 or above, but I guess you could extend this indefinitely! What Microsoft doesn't do in the current CTP is to provide any pre-canned M3 meta-metamodels (actually, that is not entirely true - there is the beginning of some M3 support in the repository). Given that they plan to deliver fulsome support for UML, and have committed themselves publically to XMI, and given their OMG membership, it is possible that we might even see Microsoft exploit MOF. If they don't do this, themselves, it will only be a matter of time before others do within the Oslo ecosystem. What I don't expect to see is any attempt to promote MOF as a one-size-fits-all M3 specification in the world of Oslo. That should not be interpreted as some conspiratorial (and completely pointless) attempt to undermine well-accepted standards. It is simply the natural consequence of remaining agnostic with regard to the number of metamodel layers needed, pragmatically, within any given context.

Jean-Jacques engages is an interesting argument about 'defining M3 properly' for implementational purposes. There is a lot in what he is saying. MOF was originally bound to CORBA IDL, and Microsoft's RTIM (an ancient specification that was roughly equivalent to MOF) was similarly bound to COM IDL. The first thing that happened when Microsoft put their specifications into the hands of a standards organisation was that RTIM was rejected as being too proprietary. Similarly, but more positively, the OMG has rigorously decoupled MOF 2 from CORBA. Jean-Jacques is, I think, suggesting that MOF still fails to adequately handle the kind of impedance mismatches that can occur when creating bindings to very different run-time representations. I will leave it to others to argue the finer points of MOF, but in terms of Oslo, the stated intention is to reduce the barrier between models and runtimes to the point of near-invisibility. The Oslo goal is to promote the direct consumption of models (including metamodels and meta-metamodels) within a wide variety of runtimes. No doubt, as Oslo evolves, we will see the advent of tooling and technologies that help developers to build the widest variety of model-driven run-times. I have a suspicion that XAML will end up being central to much of this effort.

To summarise, M3 is always there in some sense, but doesn't always need to be represented explicitly within a given context. Microsoft's historic experience of building multi-level metamodel architecture and repository technology strongly indicates that if you try to force explicit representation of M3 on your development and ISV communities, they will often ignore what you offer. Oslo does not require MOF compliance or any alternative, but is perfectly capable of supporting this as required. The ability to bind model representation at any appropriate layer of a metamodel architecture to runtime environments in a thoroughly pragmatic fashion is likely to be a core decider in terms of Oslo's future success.

I’ll take this opportunity to share an initial attempt I made earlier this year to relate, rather broadly, the core ‘M’ language artefacts to multi-level metamodel architecture and also to the ‘syntax-semantics-pragmatics’ trinity. This diagram is entirely of my own making and is in no way ‘official’ (I don’t work for Microsoft). One major weakness is that it suggests a highly repository-centric emphasis in regards to pragmatics. In reality, I expect that the use of the repository will only be one of many aspects of pragmatics. Consider, for example, the role of MGraph is enabling pragmatics at the M0 layer or, indeed, the use of ‘Quadrant’. This diagram is very much a work in progress and I will wait until future iterations before revisiting and refining this. Another issue is that, on the left-hand side, I have suggested the existence of MSchema and MGrammar grammars. These may not necessarily be made public by Microsoft, but do appear to exist.

'Oslo' SDK - January 2009 CTP

Charles Young — Wed, 04 Feb 2009 17:34:31 GMT

The latest CTP version of the Oslo SDK was released a few days ago. I spent some time yesterday installing it and having a look. From a functionality perspective, there is not very much difference to the October 2008 CTP released after last year's PDC. However, if you open up the main assemblies in Reflector, it quickly becomes apparent that the code has undergone significant refactoring and improvement. The code looks much tidier and closer to production quality. For example, the October 2008 CTP contained generated parser/lexer code for MGrammar. In the latest version, this has been removed, and it appears that the parser code is now dynamically generated at runtime (the 'preferred' Oslo approach). There has been lots of tidying up done in terms of type and method names. Additional functionality has been added to manage various issues, and the entire code base looks tighter and better constructed.

In terms of new functionality, this has been discussed elsewhere. See, for example, http://www.alexthissen.nl/blogs/main/archive/2009/01/31/improvements-and-changes-to-oslo-sdk-and-repository-in-january-ctp.aspx. Most attention has been given to the ability to include actions on the RHS of token productions. In the work we have undertaken to date, we have come across at least one situation which requires this new feature, and which we could not properly address in the October 2008 CTP.

Perhaps the most intriguing aspect of the January 2009 CTP is the way this new feature is described in the Release Notes. I suspect that Microsoft has inadvertently let slip a feature that they didn't mean to go public on. The Release Notes published on the web site state that:

"Any production in a token can now have a code action or a graph action (formerly known as term construction)! You can now specify a return type for a token definition in the case of code actions, similar to a syntax definition."

In the October 2008 CTP, actions are limited only to MGraph expressions. An action is an optional implication of a production that controls the output of the MGraph abstract syntax tree created by the parser. As far as I can tell, this is still the case in the new CTP. Unlike many similar technologies, the CTP version of MGrammar does not support the inclusion of code statements as semantic actions. This was discussed by Clemens Szyperski (an Oslo architect) in a comment to the blog article at http://weblogs.asp.net/fbouma/archive/2008/11/05/designing-a-language-is-hard-and-m-won-t-change-that.aspx, and the suggestion appears to be that this is a deliberate strategy in order to ensure that MGrammar remains (relatively) simple to write and focussed only on composable DSL creation.

The Release Notes statement suggests that Microsoft is looking at including code actions in MGrammar. As I say, it would appear that this feature is not actually supported in the January 2009 CTP. If it is, there is certainly no documentation explaining how to use this feature. Interestingly, this may be the explanation for a feature within the October 2008 CTP which seems to have disappeared from the current version. In the previous CTP, the MGrammar assembly included code for parsing C# statements. The parser didn't appear to be designed as a full-blown C# parser, but looked like it was designed to parse code statements and expressions. This code appears to be missing from the January 2009 CTP.

It is generally a fool’s errand to speculate on what is happening behind the scenes, and I certainly have no special insight or knowledge about Microsoft's intentions. However, I can't help wondering if Microsoft has accidently let us see that they are considering supporting code actions in MGrammar when it is released, and have built code to support this feature which they do not wish to make public at the current time. If this is the case, there is no guarantee that this feature will make it into the final release. For my part, I have been thinking about this issue for a few months now, and am undecided, myself, as to the desirability of supporting full-blown semantic actions in this fashion. The issue, I think, is about how useful this feature will really be in mainstream DSL creation. Does the reduced problem domain of a domain-specific language imply language simplicity that generally avoids the need to handle complex semantics at the parser level? Clearly, there is no fundamental reason why a DSL should not exhibit such complexity, but if the vast majority of DSLs are inherently simple, maybe it would be wiser to stick to the current labelled graph-only model employed by MGrammar parsers, and work around this restriction. As I say, I am undecided. It may be that the Oslo team are currently also uncertain of the best strategy. It would be interesting to hear views from the wider modelling community.

In a related issue, am I the only person to spot an uncanny philosophical resemblance between MGrammar and Labelled BNF (LBNF)? Did LBNF have any bearing on the Oslo team's thinking? The mechanics of the Oslo approach are different, and IMHO generally superior, to LBNF, but some of the underlying thinking is similar, including the emphasis on creation and shaping of labelled graph ASTs.