Agree 100%. There's little to no evidence yet of anything that, to use hanselterms, would help john doe, developer for the Nevada dept. of forestry write apps better/quicker/smarter/faster. That kind of high level abstract talk might work fine when selling biztalk licenses but not so much on developers.

Outside of maybe Don Box, does *anyone* get Oslo?

I have been trying to get someone to explain Oslo to me since PDC, and all I get is abstract theoretical discussions and a lot of "trust me, this is game changing" comments. Not much substance there that I can see.

Two words:

XML and Database. That's all you need to know about Oslo.

Oslo is Microsoft's version of the underpants gnomes:

1. Write grammar

2. ???

3. Profit!

I've tried watching videos and reading and all I get is a bunch of conceptual handwaving. If they cannot show of a working  Oslo-drvien application at the 2009 PCD then I give. Sounds great - but how does it solve real problems.

I particularly liked this example posted here:

www.hexadecimal.se/.../ARealWorldApplicationOfMGrammarOslo.aspx

Wow. Paul, that is awesome. It's even more awesome since I've been using Cucmber a lot recently, and defining a "grammar" is as simple as writing ruby code + some simple regex that any programmer could understand. It's like Microsoft has a whole department of really smart people with their heads stuck in the sand for years. Come up for air for a second!

I agree with your view. Oslo team's current focus seems to be only toward data modeling.  For Intentional Software, they need to provide the directions on how the behavioral aspect will be support by Oslo. I would love to see DSLs at business layer and may be client layer.

Whoa, Jeremy, we agree on something ;)

I don't think it's about DSLs though, IMHO it's more about application design for azure and other sql server based databases, otherwise that repository has no meaning (and it's a db inside a db anyway, which is IMHO smelly).

Intentional is doing great though, they're not releasing anything to the masses yet, but it's not on a DNF road, far from it. :) It just takes time to get to a publically usable toolkit which is usable by the masses. But that will come, and if Oslo is about DSLs (which I don't think it is), intentional will bury them before oslo even got out the door.

Yes, I agree completely. I also don't get what Microsoft is trying to solve with Oslo. I played around with MGrammar after PDC writing a DSL for browser autmation: www.codinginstinct.com/.../browser-automation-dsl-using-mgrammar.html

I found the MGrammar syntax pretty nice but it is just a parser generator and those already exist in great number. Sure Microsoft could great good tooling around it but that does not solve the real problem which is actually doing something useful with the AST, which with Oslo requires a lot of work.

I have yet to find anyone who gets what Microsoft is trying do solve with Oslo, Don Box, Douglas Purdy & co has failed completely in this regard. But the fact that the Oslo team merged with the Data team tells me it is not going be anything then yet another data access / modeling tool.

Bearing in mind it is coming out of the connected systesm team I'm pretty convinced that Oslo is part of a BizTalk replacement strategy (coupled with WCF, Workflow etc.)

OSLO is AMDD,  Aenemic model driven development

"Right now, I'm looking at Oslo and seeing nothing but a strange fixation on metadata and data modeling with little or no concern for the behavioral aspects of a system.  I think the Oslo team is doing a very poor job explaining how that Oslo metadata can be used to drive behavior in an application.."

I definitely agree, when you look at the people/teams involved it leaves you a little worried that they might be about to completely miss the point.

Hey Jeremy--thanks for taking time to read my post and to stimulate some conversation. That things are "murky"--well, I agree! I've been trying to sort through all this for a long time, and as the piece I wrote for wikipedia on "Oslo" (en.wikipedia.org/.../Oslo_(Microsoft)), the whole thing's had a history of shifting around. And as I wrote in my post, I'm still trying to work through what it's all about too. I feel your pain :)

I also compeltely agree that the story on processing metadata to drive application behavior has been very shallow to this point, and is something I'm hoping to remedy to some extent with the project I'm working on. Data modeling has gotten pretty much all the attention because, frankly, it's a lot easier to talk about.

In short, I've been asking many of the same questions you are. I didn't expect my first post there to answer them all, but to start the process. Again, I appreciate your feedback and it'll help guide some of the next pieces I'm working on.

Thank you for submitting this cool story - Trackback from DotNetShoutout

Actually Oslo wasn't about DSLs originally! MGrammar, which is the language grammar part of Oslo "M" language, is an accident :-) A quite nice accident though.

Oslo will never be about DSLs only. And explanation posts with 10 pages of meta-bla-bla wont help to understand it.

For MS, Oslo is a new tool for (Model==Data)-driven Applications. For me it is a C-style XSD and hopefully driving people to capture intents to drive behaviour.

On the behaviour-side Oslo has NOTHING! Just a crappy (sorry Clemens) API for MGraph that doesn't even support queries. I hope they will move toward behaviour, but merging with the data programability-team doesn't really support that hope.

We will hopefully see some corrections at PDC, and BTW, the codename "Oslo" will be killed by then.

I list some of it's current problems it has here:

startbigthinksmall.wordpress.com/.../updates-on-what-oslo-is-and-quadrant-not-is-september-2009

I was hoping it was going to be something like www.moserware.com/.../ometa-who-what-when-where-why.html. Now I can't tell what it is!

May be you would like check this out

msdn.microsoft.com/.../ee424598.aspx

Agreed, Oslo has a nice set of tools/technologies (especially MGrammar, Intellipad), but it would be a very sad waste if all they did with these tools was a replacement for INSERT statements. My understanding is that these tools are only "supporting tools" for some other, yet unclear, ideas; which is why the real point is hard to get.

I played with Oslo tools and the only *useful* ways I found to use them were completely alien to the ideas in the "official" examples.

Some interesting ideas (that seem to be beyond the intended scope of the Oslo platform):

* Specify complex behavior using pseudocode or domain specific language, then make that code executable by writing a parser/interpreter for it (Oslo provides the parser generator, but nothing for interpretation/execution)

* A replacement for XML configuration files (more concise/readable syntax)

* A replacement for code generation wizards - instead of repeatedly going through the same wizards hundreds of time (a very common thing when doing BizTalk development), write a few lines specifying the intent of the code to generate with a Oslo DSL (then keep that code as a source-controlled artifact and treat the generated code as a temporary, non-source-controlled artifact);

(this idea probably conflicts with the idea of using the Oslo "Repository" instead of source control)

There are already other ways to do these (ANTLR, SableCC, language-specific internal DSLs,...), but I think that what distinguishes Oslo right now is the "Intellipad" tool, which is great for getting instant feedback when editing DSL syntax or source code using that syntax.

You are right in one point, but the goal of Oslo is to not have a another modeling language but rather a to have universal meta language. Let's say you have your NHibernate to generate a meta on top of MGrammer, then on basis of that people can develop plugin for may be oracle :-) or cloud services.  Its like creating the next step for universal langauge and terminate the boudaries of  PL-SQL , T- SQL , REST etc.

Although, i do agree at first sight Oslo has big learning curve itself, but this is because it is still a on going process.

I could be wrong, light me up !!

@Mehfuz: isn't XSD/XML an universial  meta language? The M stack is much cleaner and has a quite straight syntax, but not really something new. I could think of compiling XSD down to different databases, too.

@Christos:

"...Oslo right now is the "Intellipad" tool,..."

You should check out xtext.org.. The development is fairly easy, even if it doesn't give you constant feedback as intellipad. But the editing experience is much more comprehensive.

@Lars

Its true XSD/XML is an universal meta language, but does it gives a strongly typed dataflow model that Oslo provides.

@Mehfuz: Strongly typed? The MGraph API? Can't see where it is strongly typed. Help me.

@Kraig: I said "And explanation posts with 10 pages of meta-bla-bla wont help to understand it."

I didn't read your post entirely. Sorry for initially putting it into that category! I think you got the picture quite well and I now understand what you want to say. Still it seems that you know more than you are allowed to write about :-)

@Lars

Oslo provides a nice GraphBuilder by which you can parse your M-Graph by your own MGrammer.

May be you can take a look at a tiny proudct made with it showing how things work.

www.telerik.com/.../telerik-linq-to-m.aspx

I am not saying Oslo is a big hit, but it shows way that i am sure will get better overtime. To me , i like to think a world with metas produced by NHibernate and OpenAccess , where a developer can make a Oracle support withouth modifying the code anyway using  Microsoft.M.dll and System.DataFlow.dll. May be for it , MS need to make it more simpler to get to the masses, but i guess that is the basic idea and that's what i get from Oslo.

So, far its all i have shared though my comments.

@Jeremy

Understood , thanks for clarifying.

@jeremy: There is much more to Oslo than a data format, that is for sure. And it's much more than a textual DSL-toolkit, too.

startbigthinksmall.wordpress.com/.../mgraph-the-next-xml

I've been working on a toolkit for building textual DSLs in .NET. Check it out:

http://metasharp.codeplex.com

It makes use of MGrammar from Oslo but that's about it. The core ideas are pretty divergent, metasharp is more complimentary to traditional programming models.

I'll state up front that I'm an Architect working Microsoft's IT department (MSIT) - hopefully that won't totally destroy my credibility.

I've argued this point on my blog, but I'll restate here that I think part of the problem is that Oslo is, fundamentally, not an implementation solution like ASP.NET or SQL Server. I would argue that Oslo is a solution that is aimed at a particular class of problems that are fundamentally architectural in nature.

As such, Oslo will only be interesting to a subset of Microsoft customers - customers that have the kinds of architectural concerns that need to be addressed.

I know this sounds really wonky, but the Spork example illustrates this perfectly. Oslo would actually be an interesting technology for a company like Infocom - a company in the business of making text adventure games. A company like Infocom has the economies of scale to make an investment like Oslo actually payoff (i.e., that is giving the metamodel behavior via a custom runtime).

Big IT shops may also find similar economies of scale if Oslo was used as a seed technology for what the SEI calls a Software Product Line. However, small IT shops might not have the economies of scale to make Oslo interesting.

Just my $0.02.

Here’s where I think OSLO will be useful to me: where we have model driven runtimes, but the model authoring experience is poor. For example we have a deployment process driven by a XML file, not a config file exactly, more like a nant file (i.e. it basically runs). Currently we have an app that allows users to configure their deployment, but we would rather have a deployment diagramming tool that generated this, and perhaps a textual DSL too. It looks like OSLO would do this for me.

We also generate WPF forms based on a little model that we currently keep about user scenarios. We keep the metadata in a DB, but it could equally be XML, what would be better is if we could allow users to model their UI using a little textual DSL, or a constrained UI to do the UI construction. It’s very important to us that this model is customizable so we have the intermediate model, and do not just generate WPF directly. We need to be able to let users model their UI, and then transform from our model to WPF, I think OSLO can help here too.

For older code where there is no model runtime we use the DSL toolkit so we can have a model, but we generate nhibernate mapping files, domain components etc. using T4. Going forward we will be making more model runtimes (like our deployment engine, WF etc.) and increasingly, I think, OSLO will be useful for us to make modeling tools.

Hey Jeremy,

Is it better than the alternatives? Not yet, certainly. The deployment example I gave above – we eventually wrote a DSL using the DSL toolkit (a deployment diagram that actually runs) and did a transform from the DSL model xml to our deployment engine xml. It works fine, and it was quick to do with the DSL toolkit, but I am hoping that the OSLO stuff makes it easier to define these things quickly, allows me multiple views on to the same model (deployment diagram and a textual one perhaps), and allows me to use the model as my runtime input (i.e. xml that runs, not config, Nant vs config basically). We figured we would have to change our deployment, and other models from xml to XAML (seems to be trivial with new XamlServices in 2010) and then the pieces might fit together a little easier. OSLO seems to be geared to go from n views => model and Model => runtime. If they make it easy enough to do, it should be worth using. Also it would be worth having all our models in a database, i.e. query where we have deployed service X to, How many computers are in staging etc.

RE the UI generation – it’s quite specific UI, and we already have a lot of metadata about the use case, it’s just simple workflow data capture, we certainly wouldn’t use it for app screens. It is, however currently model driven, and so it might be a good candidate for OSLO.

Perhaps the current OSLO confusion is, in part, due to current software dev not being very model driven, and being config driven instead of “runtime driven by XML” driven so people aren’t trying to solve the problems that OSLO does ?