If the answer is yes, although I don’t agree with this change in direction, I can live with it and still see a use for some aspects of the formally Oslo initiative.

If the answer is no, then sadly for many of us in the community, myself included, the #fail moniker aptly applies.

“M”
1. .NET Developers: Use “M” to create a model for a .NET application, which results in the database (schema, values, functions, .. ) and the EF types. Developers can then do whatever they want with the model; write a UI to work with it, write a service to do the same, etc.
2. .NET Developers: Use “M” to create textual DSLs over the model defined in #1.
3. Quadrant Developers: Use “M” to create and use models stored in databases and create custom viewers/behaviors
4. Quadrant Users: Use “M” to create queries and custom views over these models

“Quadrant”
1. Developers: Browse, edit, create models stored in databases (using “M”)
2. Developers: Provide custom viewers and behaviors over these models (using “M”)
3. Users: Use the custom viewers and behaviors over the models or use the in-built viewers/behaviors

“Repository”
1. Enterprise Architect/Dev/Operations: Storing conceptual, logical, and physical models of the application definition. Using these for architecture validation, application archeology, and impact analysis
2. ISVs: Many ISVs (Active Directory, SharePoint, Dynamics, etc.) already have a “repository”. Our repository is a turn-key solution for these customers. This turn-key solution is designed to save these ISVs effort and to allow us (and them)to have a great deal of sharing between these implementations

We are going to show all of this at PDC and you can use the CTP to all of these scenarios as well.

So the news about Oslo, even with your explanations that did not convince me, are very disappointing. Of course, Oslo market is not big enough to make it a full blown product. So, adding it to the DBMS/BI/MDM market is a smart move to apply the technology to bring competitive advantages.

I hope that it will enable a real Model driven approach for Master Data Management, and may be BI with SQL Server!

Anyway, Oslo will never be the same. That’s the law of product marketing and finance.

I’m so disapointed …

The text/database duality is one of the core problems that we are trying to solve. It was exactly what lead us to develop “M” in the first place.

In terms of scenarios for the repository, we think about a couple of core scenarios:

Application Structure/Development
1. storing conceputal, logical, physical models of the application definition
2. using these models to enable three key scenarios: application deployment/management, application understanding (architecture validation, application archeology, and impact analysis

Each of the above applies to the application architect, developer and operations.

We also think about key scenario for ISVs to build on, primary ISVs that already have a “repository”, like Active Directory.

There is a whole session at PDC about this.

I want to be clear, these are just scenarios for the repository.

“M” plays a role in this but it a general modeling lanuage.

But you also have to consider the data’s use cases: To me, a model is a way to specify an application’s behavior at an higher level of abstraction than typical C# code, not a way to specify that a Customer has 1..n Telephone numbers.

A very convenient way of specifying behavior is with text files, which work great to specify complex logic, and play well with diff/merge/source control tools. It’s less convenient to have that behavior specified in a database. For example, I heard of third party products developed specifically for extracting an application from the Sharepoint DB into text files that can then be manipulated in a text editor and source controlled (and then imported back into Sharepoint). I don’t do Sharepoint development, but the existence of these tools leads me to believe that there’s something missing in the “application models as pure data” principle. (Would that be a gap filled by M?)

Also, I don’t see text files as an useful solution for specifying data: why would I want a Customer’s details in a plain text file? (maybe for loading test data for automated tests, but probably not for the real data)

On the other hand, having data in a relational structure allows very powerful and flexible reporting and data mining solutions. Now, would you do data mining or reporting on a model representing an application’s behavior? (not on the data that’s contained in instances of the model, but on the model itself?).

I can see some limited examples of “data mining” on application code, with tools like NDepend, but I would need more compelling exemples to convince me of the business value of models in the database. (Like another commenter said, it would help to have concrete examples of problems you are trying to solve)

John

I kindof belong to both of these groups. You guys emphazise alot on “models are data”. And you’re right. But there is a huge difference between operational data as customers and orders and models. I know you have that vision about bluring the difference between runtime and compiletime, but lets face it – the nature of the data and the processes is totally different and therefore they need different treatment.

As for operational data, SQL is OK. We don’t need M. For operational data we care more about the actual storage than about the model-view on it. Additionally the datastructure doesn’t change too often, either. We think in transactions and use arbitrary locking mechanisms to handle concurrency issues. Concurrency issues on transactional data, BTW, is not a technical problem at all. The data and the backups are arround for decades. In this case the data is totally separate from the schema. We deploy schema changes, not data changes.

For models that define applications the story is totally different. This data is really just “code”. Whe need diff and merge, branch and tag. The deployment story is different, too. In this case the data often needs to be copied arround together with the schema. We also have need for migration-scenarios – but they are different. Backup is good, but the change history is much more important.
Also we are happy that M replaces XSD for schemas, and that in case we need it, this stuff is loaded into a database for faster queries. But really, we want a file story, too. Both for DSLs, grammars, schemas and unstructured M-values.

Maybe, some day, Visual Studio and all the C#-files are just models in a SQL Server Database. But that is still futures. Files won’t go away anytime soon, I guess. Isn’t a file-system a database?

I say “we” all time, because that is what I’ve heard from your potential customers all the way so far.

I have tons of more to say, but I guess I’ll write a blog entry, when I have more time.

- Lars

What do you think about such approach to data programming?

j.