I was going through Best Practices: Data Contract Versioning and am confused regarding what same data contracts actually means, and how we can actually create a new data contract.
I have gone through Data Contract Equivalence, and am not sure if both do mean the same.
As per below block from the specification :
Although in these examples names are changed (by appending a "2"), the recommendation is to change namespaces instead of names by appending new namespaces with a version number or a date. For example, the 'http: //schemas.contoso.com/2005/05/21/PurchaseOrder' data contract would change to the 'http: //schemas.contoso.com/2005/10/14/PurchaseOrder' data contract.
Does this imply that changing the 'Name' or 'Namespace' of a data contract makes it a new data contract, and that two data contracts are the same if they have similar values for 'Name' and 'Namespace' attributes?
Am I getting something wrong here?
Also is there any difference between same data contract and equivalent data contracts ?
Short answer: Yes: Two contracts with different namespaces are per definition, two different contracts, even if their defined operations are the same, while two contracts with the same name and namespace will be assumed to be the same contract.
The important point here is that you can have two contracts (with two different namespaces) that are still compatible or partially compattible with each other, if that is accepted by the client.
As a (somewhat dry and theoretical) example, imagine you have a contract that defines the two operations: Do-X and Do-Y. Now say you decide to remove Do-Yand replace it with the new operation Do-Z.
The best practice then is to keep the same name for the contract, but to change the namespace to reflect the change in functionality. How this will affect any clients may depend on several factors:
If a client does not validate the schema, and does not use Do-Y (but only Do-X), then that client should still be able to communicate with a service even if the service uses the new contract, and the client is still using the old one.
If a client does require schema validation, he will need to be using the same schema (namespace) as the hosted service, otherwise validation will fail.
If a client makes use of Do-Y, but does not validate a schema, you might not see any error before trying to perform the operation Do-Y, at which point it will obviously fail.
To avoid errors such as in the last example, a typical best practice is to add, but not remove operations if possible; if in the above example, you added Do-Z in the new version, but did not remove Do-Y, then a non-validating client using the old contract would still work.
If strict validation is used however, the an old client would not work with a new service contract after Do-Z was added. In fact, it would not work with a new contract even if the operations were exactly the same; Here, you might say that the old contract and the new one were equivalent (they define the exact same operations), but still not the same, since they reside under different namespaces.