Partager via

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

  • Article

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

  • Anonymous
    July 04, 2004
    The comment has been removed
  • Anonymous
    July 22, 2004
    Agreed, supporting buggy coding results in stalling the progression.