And final question is learning cycle. Model driven development still far from mainstream; introducing absolutely new specifications (M-generation) will only increase ‘entrance’ barrier.

BTW, XML-based DSMs could be used in easy (as for me much more easily than CTP Oslo) way right now with only knowledge of XML/XSL. My [A href="http://code.google.com/p/nreco/wiki/Models"]XML-based DSMs[/A] are stored as usual files so I have no problems with version control; from other hand, they may be indexed as usual text files / or using models semantic for organizing fast search in the repository. You may be interested in the DSM framework I’ve talked about: open-source project named [A href="http://code.google.com/p/nreco/"]NReco[/A].

Too many people now use the term “data model” when what they are actually talking about is a database schema. They are not talking about attributes, entities and relationships but about tables, columns, primary keys and foreign keys.

This is not a business data model but an implemented instance of all or part of such a model. There can be many such implemented instances – one for each application in a business – and all would be different.

There is a logic chasm here that developers who describe their databases as “data models” are unaware of: You can derive a database from a data model but you cannot derive the original data model from the derived database. You could make many assumptions as to what it should be but they would be merely assumptions.

So, if technology such as Oslo is to be of real use, it must be able to work on business data models and map entities, attributes and relationships, etc. Otherwise all it will do is accelerate database design further and further away from the underlying business data models that it is meant to be supporting.