Correction...
Greg Young pointed out that I inadvertently perpetuated the canonical model stuff when I said the following:
To be clear, one misconception is that we were trying to deliver on the old promise of canonical schemas, when we said one common model we meant a single shape for a given concern in the org (say Customer). Specifically what we mean is a common representation or metamodel through which one can reason about the various concepts. For example, if an ecosystem of services (say Reporting Services, Sync, Analysis Services, Integration Services, Workflow) new how to reason about a common representation for an entity and a relationship then custom apps, packaged apps and database instances that exposed the metadata about their concepts in terms of this metamodel could play in terms of tooling, integration and the basic offerings of these services. The canonical example that we use is the idea of something like MS CRM or SharePoint exposing their metadata as EDM. If they could do so and if there was a mechanism for accessing these stores in terms of the EDM (say an ADO.NET provider like Entity Client) then one could get a reporting, synchronization and ETL experience over these solutions that would be consistent with what one could get over a SQL Server database.
I spaced on that paragraph. What I should have said is a common metamodel (entities and relationships) with which one could describe shapes. An example of a shape that could be described would be a Customer in terms of a Customer Entity. There may be "n" Customer Entity Types defined in a given enterprise ... the shape customer is not the thing that is interesting to be common. The notion of an Entity and the means for reasoning about Entities in a common way is interesting.
Thanks Greg... for pointing this out.
Tim M
