It has been more quiet around “Oslo” the last month. Maybe just about everybody is on vacations. Or people feel that everything will change with the PDC in November and are afraid of publishing nonsense.
Nonetheless, I felt it’s time for an update on what I think, heard and read about “Oslo”.
I divided my post in two sections:
- Information about “Oslo”
- What I think about “Oslo” today
For those who don’t know, “Oslo” is the current codename for Microsoft’s forthcoming modeling platform, which is available as CTP Download since back in October 2008.
If you want to read more about what Oslo is about, I recommend those Resources:
The community did also care a lot, and there are even companies investing in tools around “Oslo”. Telrik published two projects on their Labs Site. A tool for comparing and migrating M as well as LINQ to M. There are even trainings offered by Agilitrain and PluralSight.
Some recommended links:
What I think about Oslo today
(May CTP + Announcements)
First of all I want to say, that I’m happy Microsoft released Oslo in such an early state. I think they know the pros and cons of such an open process. The community can help with forming the product, and companies can start to invest early in what they think might be valuable for the future. But It also means more friction for any changes that are made.
I have used M for defining schemas and languages and also played around with the Repository and Quadrant. As Microsoft also states, it’s early Alpha. I stumbled over many bugs which I still plan to report and blog about. But that is OK, no one ever said it was production ready.
So far I like the schema part of M, also called MSchema. It has a very concise (compared to XSD) c-style syntax and covers a lot of what I want to express when modeling information structures. The M-graph (for values) syntax is also OK, while I don’t like the MGraph API. M-constraints let you restrict your types in a nice way. What I don’t like here, is the missing support for weak constraints. Named M-queries (similar to LINQ syntax), are a nice way to query M structures.
M-grammar is useful for DSLs. I think it could be more opinionated. I feel MS is striving for an expressiveness that let you describe all computer languages in the world using MGrammar. This makes it more complex than necessary for covering DSLs. At the same time it doesn’t support nesting of languages, which would be especially useful for DSLs, because you often need to talk to external models (e.g. pinvoke). The support for editor customizing (crucial language workbench feature) as it is today is not sufficient and too hard to configure.
Another feature I miss here is referencing between nodes and even across files (linking + scoping). For now all references are just values (ids), and the output of a DSL program will be a tree model, no graphs!
The Repository basically offers some features on-top of SQL server as are row-level security, hierarchies, localization, versioning, additional constraints. All those features are plain SQL “libraries” in conjunction with M-models which also are compiled down to SQL. I don’t yet know what to think about the Repository.
Naming / Packaging
In the last couple of weeks the Oslo team published two posts that confirmed some of my speculations.
Let’s start with Doug’s Post: On “Oslo” at Douglas Purdy
In this post he basically makes two statements:
The only thing that I feel bad about is that we kept the “Oslo” name around so long (you will see that change at the next PDC), which has continued to be a confusing point for customers (“I thought Oslo was your new SOA platform”).
I agree. It was confusing. Although people slowly start to accept “Oslo” as for “Modeling”.
Oslo and EF / Data Programmability
With this in mind, we made a decision to merge the Data Programmability team (EDM, EF, Astoria, XML, ADO.NET, and tools/designers) and the “Oslo” team (“Quadrant”, Repository, “M”) together.
I don’t yet know what to think about this. “Oslo” is not and should not evolve to an O/R-Mapper. M’s type system is structural and doesn’t map well to strongly typed objects as used by EF. I can see this choice limiting the modeling capabilities of Oslo. But I guess we have to wait and see.
Quadrant. A graphical Editor?
The other post, confirming my fears about Quadrant was Model Citizen : What’s So Compelling about "Quadrant" Anyway?.
Back in November last year, when I wrote a sum-up post about “Oslo” I concluded Quadrant:
Yes. Quadrant lets you interact with models graphically. It’s highly generic, customizable and it looks great.
Lars Corneliussen, November 2008, What "Oslo" is and is not
I concluded this from the official statement about Oslo plus some videos and screenshots I had seen.
A tool that helps people define and interact with models in a rich and visual manner
Doulas Purdy, September 2008, What is Oslo?
But here is the smackdown:
Microsoft code name "Quadrant" is a ‘tool for viewing and editing SQL data,’ but… so what?
Michael Murray, July 2009, What’s So Compelling about "Quadrant" Anyway?
As I understand today, and as it shows up in the May CTP, it is not a graphical editor or graphical editing toolkit but rather a light WPF-version of Microsoft Office Access that understands Oslo Modeling concepts and relationships and builds up default editors in a generic manner. This is still useful (if it is free), but not far as useful as what I hoped Quadrant to be.
Please, Microsoft, make Quadrant a graphical editing toolkit with good support for configurable diagramming and any custom WPF editors. It should also have the plug-in model VS2010 offers for sharing any extensions.
The “Oslo” Story
Microsoft tries to sell “Oslo” as if it was all one story. It’s a lie.
There is tons of impedance mismatches that restrict you in many ways.
- M in general uses structural typing (duck typing, supports mix-ins) and supports real graphs (including references)
- MGrammar ASTs are hierarchal (tree structure) and for now only supporting nodes and strings.
- Databases store flat relational data,
- and objects in the .NET world are typed nominally (no multiple inheritance).
DSLs + Repository
There is no story for “DSLs and the repository”, and there is not yet a good story for any runtime support off the repository or DSL files. It’s basically what you had before. You can either access the database via ADO.NET or an O/R-Mapper or you run directly off the parsed MGraph-AST representing your DSL-Script, which feels like visiting xml documents. M has a nice LINQ-ish query language, but that doesn’t work in memory against a graph.
M has good support for complex data structures. As said there is no support for in-memory queries. But even the database implementation is limited by it’s relational backend. Even though queries can consult complex properties for sorting or filtering, it can only return rows with a list of scalar fields.
Most constraints on types are only implemented in the SQL-Mapping. Also here there is no in-memory implementation that would validate your model against a schema. Basically the M-compiler generates a database schema including checks that would not let you insert invalid data into the database.
Data and schema evolution
There is this dream about capturing requirements in quite fuzzy ways and then piece for piece add details to them – until they have reached some formal state that might be executable. This sounds nice in theory, but there is no chance to implement this stuff. M is very easy to change, and it is easy to add constraints and refactor schema structures. But there is no story around how to let your data evolve together with your schemas using the Repository. So, besides nice theories, Oslo doesn’t help here.
More to come
There will be new content and Chris Sells also announced a fresh CTP around this years PDC in November.
So far, only one session has been scheduled, but watch this list for more sessions to come: Microsoft PDC09 – Modeling Sessions
Hope to see you in LA in November!