Within Microsoft, we use two different terms to describe versioning: breaking change & non-breaking change. I say this because many times people believe that only non-breaking changes are “versioning”. 😉 That said, both play an important role in the overall versioning story we support in Indigo.

In terms of data contract versioning (and therefore XSD — since Indigo maps the abstract notion of a data contract to a schema and back), we support both non-breaking and breaking changes — although we certainly recommend that you know what you are doing when you introduce a breaking change. An incomplete list of what is a breaking change and not follows:

Non-breaking change
Adding a new data member
Breaking change
Changing the data contract namespace or local name
Mutating a data member’s attributes in a incompatible way (we haven’t revealed some of these features so I am not going to talk about this)
Removing a data member (there is a case where this is not a breaking change — but I can’t go into it)
The key takeaway from the above is that data contracts are mutable. You may change them without breaking existing services and clients — assuming that you only make non-breaking changes. You may also change them in such a way that existing services and clients fail to work with the mutated contract. One great way of doing this is to change the namespace of the data contract.


Suppose I have the following class:

public class PurchaseOrder {

public object[] LineItems;

public Dictionary<string, string> CompanyContacts;

public Nullable<DateTime> OrderDate;

public event LineItemAddedEvent;

public IAddress ShipToAddress;


First, could you tell me what the schema should be?

Second, could you tell me what each particle of the schema means?

Since I know that I will receive any number of different answers to the above, maybe we should just make the world a better place by not using PurchaseOrders in WebServices at all.


This morning we announced the formation of the “M” Specification Community (MSC) at MIX09.

The MSC is a group of individuals and organizations throughout the software industry working together to develop the “M” language specification.

Our goals with the MSC are two-fold:

Ensure the broadest possible support for “M” with a number of “M” implementations across multiple platforms and excellent interoperability with existing standards/approaches.
Ensure that we have the best possible language that can span the presentation, services and data domains and is well informed by the XML, modeling, and Web communities.
The MSC is a key part of our broader strategy to move the industry toward model-driven development and unlocking the value that this approach provides to our customers and partners.

This community will function primarily through a public discussion list, just like other public specification efforts, with the goal of a good interchange of ideas that will lead us to the best possible language with the broadest industry support.

The MSC has already shown a great deal of promise toward our goals as two key open-source technical leaders will serve as “charter members” of the community: James Clark (Technical Lead of the XML WG and Editor of the XSLT 1.0 Specification) and Ed Merks (Technical Lead of the Eclipse Modeling Framework and PMC (Project Management Committee) Lead for the top level Eclipse Modeling Project).