Upcoming Changes to System.Xml in .NET Framework 2.0 Beta 2

We are in the process of locking down System.Xml for Beta 2 of the .NET Framework 2.0 and Visual Studio 2005. In the past few months we have received customer feedback about our feature set previewed in the Whidbey Alpha & Whidbey Beta 1 and this has guided our decision making process as to where to focus our energies to ensure a comprehensive feature set.

Below is the list of changes to System.Xml and subsidiary namespaces that have occurred between Beta 1 and Beta 2 of the .NET Framework 2.0 release.



The XmlSchemaValidator class provides a push model API for W3C XML Schema validation. The primary scenario for using the XmlSchemaValidator is for validating an XML infoset in-place without having to serialize it as an XML document then reparse the document using a validating XML reader.



  • Added overloads to the static Create() method that take XmlParserContext
  • ReadValueAsXXX() methods renamed to ReadContentAsXXX(). Also reduced the number of ReadContentAsXXX() methods relative to the number of ReadValueAsXXX() methods in Whidbey beta 1.
  • Added ReadElementContentAsXXX() methods which are specific to obtaining the value of element nodes
  • Added methods for reading large streams of text or binary data embedded in an XML document in a streaming fashion

public virtual bool CanReadValueChunk { get; }

public virtual int ReadValueChunk (byte[] buffer, int startIndex, int count);

public virtual bool CanReadBinaryContent { get; }

public virtual int ReadContentAsBase64 (byte[] buffer, int startIndex, int count);

public virtual int ReadContentAsBinHex (byte[] buffer, int startIndex, int count);

public virtual int ReadElementContentAsBase64(byte[] buffer, int startIndex, int count);

public virtual int ReadElementContentAsBinHex(byte[] buffer, int startIndex, int count);

  • Added ReadToFollowing(string localname, string namespaceURI) which moves to the next occurrence of the named element in document order.


  • Added XmlSchemaValidationFlags enumeration to replace the following flags; IgnoreInlineSchema, IgnoreSchemaLocation, IgnoreValidationWarnings and IgnoreIdentityConstraints
  • Added existing ValidationType enumeration to replace to replace the following flags; DtdValidate and XsdValidate


  • Reduced number of WriteValue() methods
  • Removed overloads of WriteStartElement and WriteStartAttribute that took an IXmlSchemaInfo parameter


XPathNavigator and XPathEditableNavigator

  • The XPathEditableNavigator has been merged into the XPathNavigator, making it an editable XML cursor model API.
  • The XPathNavigator is the preferred API for exposing data as XML. This has been incorporated into the design guidelines for using XML in the .NET Framework


  • The XPathNavigator returned by the CreateNavigator() method now allows one to edit the XmlDocument through the cursor model API.
  • The XmlDocument now supports XML schema validation of the entire subtree or partial validation of nodes in the document using the Validate() method
  • The following property added to XmlDocument

public XmlSchemaSet Schemas { get; set; }

  • The following property added to XmlNode

public virtual IXmlSchemaInfo SchemaInfo { get; }


  • The XslTransform class was obsoleted in Whidbey Beta 1 and replaced by the System.Xml.Query.XsltCommand class.  In Beta 2, we decided to revamp the XsltCommand API in order to make migration from XslTransform simpler.  This effort also resulted in the renaming of the XsltCommand class to  System.Xml.Xsl.XslCompiledTransform.
  • XslCompiledTransform compiles XSLT to MSIL for significantly improved performance at the cost of increased (yet still small) compile times.
  • Supports the MSXML XSLT extension functions such as format-date, format-time etc.


  • This class has been renamed to XmlSchemaInference

XPathExpression –

  • Added static Compile() method enables one to compile an input string containing an XPath query into an XPathExpression object



To reduce the cost of churn caused by the obsoletion of XslTransform this class has been removed. In its place the XsltArgumentList from v1.1 can be used


Microsoft has decided not to ship a client side XQuery implementation in .NET Framework 2.0 as our customers expect us to ship an implementation that meets the following criteria:

  • Compliant with the W3C standards
  • Functionally addresses key scenarios

As a core platform component in Windows, they also expect us to ship a product that meets the high bar of not breaking their applications when future updates are released.  After talking to key customers and partners, we have determined it is important that we cross this high bar before shipping a full implementation of XQuery in the platform. 

The best estimates tell us that ETA for XQuery to become a W3C recommendation is end of 2005 which does not fit with the .NET Framework 2.0 product release cycle.

In the meantime, we are shipping a well-defined small subset of XQuery in SQL Server 2005 to query information stored natively as XML data type.  This will enable new customer scenarios in SQL Server for storing and retrieving semi-structured data.

In the NET Framework 2.0 RTM timeframe, we recommend that our customers continue to use XSLT and XPath on the client side to solve their key client side filtering and transformation scenarios.  With this in mind, we have made significant improvements to our client side story including:

  • Performance improvements – making the .NET Framework XSLT processor the best performing processor.
  • Functional improvements – improving the usability and feature set of the existing .NET Framework processor

Note: As a result of not shipping XQuery, XML Views using mapping and XQuery to query SQL Server 2005 and the XmlAdapter to perform updates that were originally previewed in the PDC Alpha release of .NET V2.0 have also been removed. These were removed in the Beta 1 release.

Comments (27)

  1. For the love of God! Why do you practically duplicate the Stream "interface" (and when is Stream going to be an interface and not an abstract class?) with some oddly named methods? Wouldn’t it have been a much more better design to have one method Stream ValueChunk() which returns null in case it cannot return the chunk, otherwise a stream which performs the reading? Oh well, it’s just one MORE wrapper to write…

  2. anonymouse says:

    Hi Dare,

    Great work as usual… however, do you know what the status of KB 317611 (support for Chameleon Schemas is?)…

  3. Sriram says:

    The .NET XML classes are well-grained and powerful..but..err..a bit complex when compared to MSXML. Check out http://www.nedbatchelder.com/blog/200410.html#e20041012T161950 for a good example of what I mean

  4. The XQuery part is a major ARGGGGGHHH!

    And, no, supporting XQuery in SQL server is no stopgap for that; I’m interested in applying XQuery on local XML files, I’m not interested in SQL server.

    Is there any hope that the existing XQuery support will be released somehow as a stand-alone technology (‘unsupported’ if deemed necessary)? Or do we have to use ILDasm/Ilasm on the whidbey beta 1 files to ‘extract’ an assembly with those classes ourselves?

    I perfectly well understand your reason for not supporting a ‘standard’ that is not going to be a standard for some time, but retracting the existing XQuery part from whidbey beta 2 means that there isn’t even an experimental XQuery implementation for the .NET framework around, anywhere. Because after Microsoft announced that they would support XQuery in Whidbey noone in their right mind would start designing their own XQuery implementation for .NET. So there are no third party implementations.

  5. Luc,

    If you feel you need an implementation of XQuery for the .NET Framework right away you can take a look at the Saxon.NET project hosted at http://www.x2x2x.org/x2x2x/home/


    The problems with chameleon schemas are fixed in Whidbey. I seem to remember us considering whether to fix this in Everett SP1 but I’m not sure if we ever did.

  6. Still no easy way way to choose encodings other than UTF-16 for XmlDocument?

  7. RichB says:

    Does the lack of an XQuery implementation affect your decision on XSLT 2? (see http://blogs.msdn.com/mfussell/archive/2004/05/13/130969.aspx)

  8. Ken Brubaker says:

    Dare Obasanjo shares an important update on the Beta 2 version of System.Xml 2.0.

  9. .NET Framework 2.0 beta 2 で System.Xml が変わる

  10. Don Richer says:

    I second Luc Cluitmans comments. XQuery is key to our strategy and we need a non SqlServer approach even if unsupported and experimental.

  11. Kent Tegels says:

    While I understand the desire for XQuery on the client, are you sure you’d rather have partial support and, potentially, a client that doesn’t align well to the standard deployed on every client you want to touch? That makes me jumpy. Don and Luc, I’d like to hear more about your use cases, too. Follow the link for more contact info.

  12. I have to third the comments by Don and Luc. Since when has Microsoft let a little thing like standards get in its way? But seriously folks, what do different clients have to do with anything? For example, we have an n-tier app. We have our own Windows.Form thin client talking to a server using Web services. All processing is done on the server. This is especially pertinent to XQuery as that’s what would be ideal to push sparse data to the client. Please, please, please. Microsoft has always been very accessible in early beta stages of products. Don’t rip out XQuery now.

  13. Emerson says:

    Consitency ?

    You have refactored the ReadValueAsXXX() methods to be a much more appropriate ReadContentAsXXX(). Appropriate becuase the name of the method reflects the domain knowledge. Xml has content not value !

    But then you’ve left other methods called CanReadValueChunk(), that makes no sense at all.

    And why are you duplicating functionality. Whilst it may seem attractive to have all the features in one place, adding methods like ReadElementContentAsBase64() just polutes the simplicity and dilutes the consistency of the API.

    Your duplicating functionality in an unneccessary and inconsistent way.

    Surely it would be better to have one or two methods like ReadElementContentAsStream() and ReadElementContentAsByteArray() and allow people to use System.Convert or whatever other standard feature exists for this task.

    Making a half effort to support a couple for encodings it pointless when there are guaranteed to be more, so always implement the base functionality and no more.

    If your going to design an API, or an object model which you expect other people to use you may as well use it yourself otherwise its just hypocracy… not to mention bad design.

  14. Steven,

    I feel your pain! XQuery in the middle does make sense and would have a smaller change management foot print.

    Just a thought: Suppose you installed an instance of SQL Server 2005 Express on the local app server. It wouldn’t any normal database work, other than have procs that take your XML and XQuery parameters and then return results to you. Would that work?

    As much as I love XQuery, I’d rather not have it in Whidbey for a number of reasons. See http://sqljunkies.com/WebLog/ktegels/archive/2004/10/13/4584.aspx

  15. question says:

    Over the weekend, I tried performing stylesheet transformation using the XslTransform class only to find that vbscript is not supported. Any plans to change this in the upcoming version?

  16. The XslTransform class only supports the primary Common Language Runtime languages which are VB.NET, C# and JScript.NET

  17. I may be misunderstanding the purpose of XmlWriter.WriteValue, so I am sorry if this is way off. In the docs for XmlWriter.WriteValue( DateTime ), it says "If no parent type is available, the value is typed using the default mapping; thus, a DateTime value is mapped to the xsd:dateTime type."

    According to http://www.w3.org/TR/xmlschema-2/#dateTime, the format should be in CCYY-MM-DDThh:mm:ss, but it looks like you are using CCYY-MM-DDThh:mm:ss.sssssss-HH:MM. I think that your representation may be valid as ISO 8601 goes, but as it is, there are two major problems: 1) a time zone is being pulled from outside of the DateTime which invalids it as a representation of the original DateTime and 2) that format is not supported at all in the W3C recommendation.

    It is possible that I am misunderstanding the W3C recommendation (or maybe it has changed), but on the time zone, I think that WriteValue is wrong. The data going into the XML should represent the object, not the instance with a system context appended to it. An example is below.

    using System;

    using System.Xml;

    public class Test {

    public static void Main() {

    XmlWriter writer = new XmlTextWriter( Console.Out );

    writer.WriteStartElement( "SomeDate" );

    writer.WriteValue( DateTime.Now );







    I think that the output should be…


    Thank you for your time.

    – jeremiah

  18. I was doing some catch up reading feeds I’m subscribed and I found this one item that made me feeling some sort of bitter nostalgia. It’s right on MSDN TV site, a new episode where Mark Fussel explains new XML features in upcoming .NET 2.0. The episode is dated December…

  19. Btw, talking with .NET developers recently (XML geeks and non-geeks) about XQuery and XSLT support in .NET 2.0 I realized that shocking fact – about 80% of devs I was talking to still have no idea XQuery support in .NET 2.0 was cut. They were listening all the road to…

  20. Almost 6 months after it’s been announced that Microsoft won’t ship XQuery implementation in the .NET 2.0, StylusStudio (maker of the namesake XML IDE) decided to run an online petition &quot;XQuery for all&quot; to urge Microsoft change the mind. Well, as a marketing action it’s ok, but the petition itself…