Breaking Changes in System.Xml from v1.1 to v2.0 of the .NET Framework


At Microsoft one of our goals in developing software is that backwards compatibility when moving from one version of software to the next is high priority. However in certain cases the old behavior may be undesirable enough that we break compatibility. An example of such undesirable behavior are bugs that lead to incorrect results or security issues. Below is a list of breaking changes in the System.Xml namespace in beta 1 of v2.0 of the .NET Framework.




  1. Extension of xs:anyType which changes the content type to mixed=”false” results in error.
  2. Add an enumeration member to XmlWriter.WriteState to indicate that the writer is in error state. Change writer to disallow further writes when in error state.
  3. ##other namespace constraint now treated correctly on wild cards.
  4. Instances of DateTime object returned by XmlValidatingReader that represent xs:time and other date & time related W3C XML Schema types now initialized using DateTime.MinValue
  5. Incorrect implementation of XSD derivation hierarchy for xs:ENTITY and xs:NCName corrected.
  6. XSD List Types Not Validated Correctly.
  7. Changed to reliably fail when XmlTextReader source stream switches encoding between calls to ResetState()
  8. XmlTextReader should apply the same security restrictions as the XmlReaders that can be created via the static XmlReader.Create() methods

I was directly involved in the decision making process for most of these breaking changes since many are in the W3C XML Schema area which I am responsible for. If any further clarifications about any of the breaking changes is needed, please post a comment with your question below.


Comments (2)

  1. These only look like breaking changes for people that did stupid things in the first place that they shouldn’t have….

    Good work in changing these! If this type of thing had been done with previous versions of windows instead of making other people’s buggy crap work when it shouldn’t have, Windows would be much further along!

    If this is the new policy, I am so happy! Keep it up!

  2. xml training says:

    Agreed, supporting buggy coding results in stalling the progression.

Skip to main content