Grouping

When working with Xml documents it is common to have a list of elements that contain an attribute whose value can be used to qualify a given element to a group. As opposed to Xslt 2.0 which contains the xsl:for-each-group instruction Xslt 1.0 does not natively support grouping. It’s probably one of the biggest (if not the biggest) weaknesses of Xslt 1.0. Although not that straightforward it is still possible to group items in Xslt 1.0. There are basically two techniques for doing this:

• Simple grouping (*not really recommended*)
• so-called Muenchian grouping

Simple grouping is just looking for keys using preceding-sibling (or following-sibling) axis (something like: item[not(preceding-sibling::item/@group = @group)]). While it may work fine for small sets its performance is horrible and therefore using this method is not recommended. Instead you should group your items using so-called Muenchian grouping which is based on using keys and is way faster than simple grouping (also more complicated). You can find more details on Muenchian grouping in Wikipedia: http://en.wikipedia.org/wiki/Muenchian_grouping. The article also contains a link to in-depth explanation of how Muenchian grouping works.

Regular expressions

It’s not easy to work with strings in Xslt 1.0 let alone regular expressions. A lot of new string functions were introduced in Xslt 2.0. In addition a new instruction xsl:analyze-string enables using regular expressions. While most of the new string functions can be emulated in Xslt 1.0 using existing functions or (recursive) templates this is not the case with regular expressions. In this case the workaround is to use either scripts or extension objects in which it is possible to use regular expressions from .NET Framework. An example that uses an embedded script is shown below:

<?xml version="1.0" encoding="utf-8"?>

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"

    xmlns:msxsl="urn:schemas-microsoft-com:xslt"

    xmlns:my-scripts="urn:my-scripts"

    exclude-result-prefixes="msxsl">

  <xsl:output method="text"/>

  <msxsl:script language="C#" implements-prefix="my-scripts">

    <![CDATA[

    public bool ValidateEmailAddress(string emailAddress)

    {

      return Regex.Match(emailAddress, @"^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,4}$").Success;

    }

    ]]>

  </msxsl:script>

  <xsl:template match="/">

    <xsl:variable name="addresses">

      <email>john@contoso.com</email>

      <email>john@contoso</email>

    </xsl:variable>

    <xsl:for-each select="msxsl:node-set($addresses)/*">

      Address <xsl:value-of select="." /> is <xsl:if test="not(my-scripts:ValidateEmailAddress(.))">not </xsl:if>valid.

    </xsl:for-each>

  </xsl:template>

</xsl:stylesheet>

XHTML output method

In addition to Xml, Html and Text output methods available in Xslt 1.0 Xslt 2.0 introduces a new output method which is XHTML. Fortunately XslCompiledTransform allows for providing your own XmlWriter that will be used to write transformation results. If you provide a specialized version of XmlWriter that can write XHTML compliant documents you will be able to achieve the same functionality as the one enabled by Xslt 2.0. If you don’t have such a writer handy you can use the one that is part of Mvp.Xml library (http://mvpxml.codeplex.com/). See Oleg Tkachenko’s blog entry for some additional details http://www.tkachenko.com/blog/archives/000712.htm

DateTime support

There is no DateTime type defined in XPath 1.0. As a result working with date time in Xslt 1.0 is not easy. Xslt 2.0 on the other hand adopted uses XPath 2.0 type system. As a result DateTime type is first class citizen in Xslt 2.0. How to go about DateTime type in Xslt 1.0? Here are a few ideas you may try depending on your needs:

• Consider using ISO 8601 date format – it is easy to sort, compare and get date parts
• Check the built-in extension functions for formatting date and time (http://msdn.microsoft.com/en-us/library/ms256453.aspx)
• If none of the above works you may need to use scripts or extension objects

Techniques for emulating Xslt 2.0 features with Xslt 1.0 processor can be summarized as follows:

Some of the workarounds I provided may require using scripts. If you are concerned about portability (using scripts will make your Xslt stylesheet not portable) you may want to use EXSLT (http://exslt.org) – a set of well-defined extensions for Xslt 1.0. XslCompiledTransform supports natively only two functions from the EXSLT set (exsl:node-set() and exsl:object-type()) but you can use EXSLT.NET module from the Mvp.Xml project (http://mvpxml.codeplex.com/wikipage?title=EXSLT.NET&referringTitle=Home). Since EXSLT is supported on quite a few platforms you should be able to create portable stylesheets.

Pawel Kadluczka

Obsolete APIs are easy since the compiler helps identifying them but there are two more APIs you should avoid using – namely XmlTextReader and XmlTextWriter. We found a number of bugs in these classes which we could not fix without breaking existing applications. The easy route would be to deprecate these classes and ask people to use replacement APIs instead. Unfortunately these two classes cannot be marked as obsolete because they are part of ECMA-335 (Common Language Infrastructure) standard (http://www.ecma-international.org/publications/standards/Ecma-335.htm) – the companion CLILibrary.xml file which is a part of Partition IV).

The good news is that even though these classes are not deprecated there are replacement APIs for these in .NET Framework already and moving to them is relatively easy. First it is necessary to find the places where XmlTextReader or XmlTextWriter is being used (unfortunately it is a manual step). Now all the occurrences of XmlTextReader should be replaced with XmlReader and all the occurrences of XmlTextWriter should be replaced with XmlWriter (note that XmlTextReader derives from XmlReader and XmlTextWriter derives from XmlWriter so the app can already be using these e.g. as formal parameters). The last step is to change the way the XmlReader/XmlWriter objects are instantiated – instead of creating the reader/writer directly it is necessary to the static factory method .Create() present on both XmlReader and XmlWriter APIs. The factory method will create and return an implementation of XmlReader/XmlWriter depending on the settings (XmlWriterSettings/XmlReaderSettings) passed to the .Create() method (or default settings if no settings were passed). This pattern allows for introducing new settings and new implementations of XmlReader/XmlWriter classes in the future without having to change or add new APIs.

Pawel Kadluczka

OutOfMemoryException (a.k.a. memory leak)

This is one is pretty easy. It can happen when you combine embedded scripts or loading stylesheets in debug mode with the not recommended way of using XsltCompiledTransform. The recommended way of using XslCompiledTransform is to load an Xslt stylesheet once and re-use the instance the stylesheet was loaded to for further transformations. Loading the same stylesheet repeatedly should be avoided. The main concern here is performance. XslCompiledTransform.Load() does not mean only “load the stylesheet” but “load and compile the stylesheet”. This is the “compile” part that makes .Load() expensive. There is more to the story though. In some cases when compiling a stylesheet the compiler will create assemblies on the fly. When does this happen? Easy to guess - either when you are using scripts in your stylesheet (to compile scripts the compiler uses CodeDOM which creates assemblies containing compiled code for the scripts) or when loading a stylesheet in debug mode (necessary to make stylesheet debugging work). Why is this important? The dynamically created assemblies are loaded into the AppDomain. Once they are loaded they cannot be unloaded (CLR does not allow unloading a single assembly from an AppDomain – the only way to unload an assembly from an AppDomain is to unload the whole AppDomain). So, if you load a stylesheet in debug mode or a stylesheet containing a script repeatedly you will see that your app is consuming more and more memory. The reason for this are the dynamically created assemblies that cannot be unloaded (Houston, we’ve got a leak!). Eventually, so many assemblies have been created and loaded that it is not possible to load yet another one and you get the OutOfMemoryException. If you just load a stylesheet with a script once (you should avoid loading stylesheets in debug mode in production environment entirely) and re-use the object there will be only one assembly created for your script and you should not see the OutOfMemoryExceptions caused by the Xslt. Most likely you will also see a perf boost which is a result of not compiling the stylesheet many times. Another way to resolve the problem is to compile the stylesheet “offline” (i.e. not at runtime) with the xsltc (xslt compiler, more details in MSDN http://msdn.microsoft.com/en-us/library/bb399405.aspx). This tool will create “regular” assemblies (.dll files) for the Xslt stylesheet and the embedded scripts. To be able to use them in your app you just need to add references. The memory leak problem is resolved – there is no compilation going on at runtime so no temporary assemblies are created.

StackOverflowException

This exception is bad. It brings the whole process down and there is nothing in your app you can really do about it (starting from .NET Framework 2.0 StackOverflowException is not “catchable”). When using XslCompiledTransform you can get this exception either when the Xslt stylesheet is being compiled or when the transformation is being performed.

StackOverflowExceptions thrown when compiling the stylesheet are rare. There can be just a couple root causes of this problem:

• You have a pretty big xsl:choose instruction. “Big” means here a thousand or more xsl:when instructions inside this single xsl:choose instruction on a 64-bit machine when there is ~256KB of stack remaining (see notes below for more details). The fix is simple – refactor the stylesheet.
• If you use xsl:choose just to simulate a dictionary replace it with a variable containing an xml fragment with key-value pairs and use XPath expressions to access it. So, instead doing this:
  
  <xsl:template name="countries">
    <xsl:param name="country-code" />
    <xsl:choose>
      <xsl:when test="$country-code = 'AF'">Afghanistan</xsl:when>
      <xsl:when test="$country-code = 'AX'">Aland Islands</xsl:when>
      <xsl:when test="$country-code = 'AL'">Albania</xsl:when>
      <!—... -->
    </xsl:choose>
  </xsl:template>
  
  try this:
  
  <xsl:variable name="countries">
    <item code="AF">Afghanistan</item>
    <item code="AX">Aland Islands</item>
    <item code="AL">Albania</item>
    <!—... -->
  </xsl:variable>
  
  <!—... -->
  <!-- get the value –>
  <xsl:value-of select="msxsl:node-set($countries)/item[@code='AX']"/>
  
• If you use xsl:choose to do different kinds of processing depending on values of elements/nodes/attributes – move the contents of the xsl:when instructions to separate templates and use xsl:apply-templates to invoke them (or have the default template invoke them). So, instead doing this:
  
  <xsl:template match="/">
    <xsl:choose>
      <xsl:when test="/root/name">
        <!—... -->
      </xsl:when>
      <xsl:when test="/root/address[@country='US']">
        <!—... -->
      </xsl:when>
      <xsl:when test="/root/address[@country='IE']">
      </xsl:when>
      <!—... -->
    </xsl:choose>
  </xsl:template
  
  try this:
  
  <xsl:template match="/root">
    <xsl:apply-templates select="name" />
    <xsl:apply-templates select="address" />
    <!—... -->
  </xsl:template>
  
  <xsl:template match="name">
    <!—... -->
  </xsl:template>
  
  <xsl:template match="address[@country='US']">
    <!—... -->
  </xsl:template>
  
  <xsl:template match="address[@country='IE']">
    <!—... -->
  </xsl:template>
  
• You have an xsl:template instruction whose match attribute contains a lot | (pipe) separated matches or you have a lot of templates in a given mode. Again “a lot” here depends on the free space on the stack (see notes below for more details) but it usually means at least a thousand on a 64-bit machine with the smallest possible stack size. To fix this try one of the following:
• Try changing match value to * and use xsl:if with the original match value inside the template to filter nodes you want to process
• Try moving the template with a lot of | pipe separated matches to a different mode
• If the above does not help move some (half?) of the templates to a different mode (if you have a template with a lot of | separated matches move the body of the template to a named template and create two or more templates in different modes. Each of these templates should contain some of the matches from the original template and should call the named template you had created. Obviously you need to fix up the places you invoked the original template as well). I agree this just a workaround which is not pretty but having thousands of matches is not common and the compiler was not optimized to handle this kind of situations.
• See http://social.msdn.microsoft.com/forums/en-US/xmlandnetfx/thread/6edac9a7-0cf0-45a6-b196-c4308b54b937/ for more details and ideas

There are a few additional interesting notes:

• Whether you see the stack overflow or not depends on two things:
• How much of the stack is left when you start the compilation. This in turn heavily depends on how big the stack of the current managed thread is. The default size of the stack of a managed thread is 1MB. However managed threads created by IIS have by default stacks of 256KB.
• How big the stack frames are - stack frames on AMD64 are in general much bigger than stack frames on x86 so nested method calls on AMD64 “eat” the stack much faster than on x86.

The conclusion is that web apps running on 64-bit machines are more prone to this problem than non-web apps or apps running on x86 (In fact I don’t remember this problem being reported for non-web apps).

Other Workarounds

Disclaimer: I believe that most Xslt stylesheets hitting this problem are poorly written. Usually aside from issues with compilation their performance is also bad. I strongly believe that the *right* way of addressing these kinds of issues is to refactor/fix the stylesheet.

In case it is not possible for you to refactor the stylesheet:

• To avoid this problem happening at runtime where the size of the stack is limited you can use the xsltc (Xslt compiler) to precompile your stylesheet. As a result the compilation is not happening at runtime so you won’t get this exception. A nice side effect of doing this is the performance boost your application will get.
• You can “fix” the issue by increasing the size of the stack for the thread the stylesheet is being compiled on. But beware. There was a reason why the stack size was limited so increasing it may cause other problems.

Stack overflow thrown when transforming an Xml file.

This one is pretty common and there is one main root cause – your stylesheet is using very deep or infinite recursion. Recursion is the way to emulate “regular” loops (like for, while etc.) in Xslt. Now, if you have a bug in the stylesheet and you never stop the recursion or the recursion is deep you can get the StackOveflowException. It’s not different from other .NET languages like C# or VB where infinite or very deep recursion will result in the same exception. If you have a bug – fix the bug and you should be good to go. If the reason is the deep recursion then it’s a bit more difficult. Obviously you need to change the stylesheet to fix it. There is a couple of things that you can try doing:

• Avoid the recursion at all. Sometimes people are using recursion because it’s easier or nicer even though there is a viable non-recursive approach. Go for it.
• Use “divide and conquer” approach (http://en.wikipedia.org/wiki/Divide_and_conquer_algorithm). This will reduce the size of the stack needed to execute the template. For instance if you have a loop that writes numbers from 1 to 1000000 and you use the simple recursion for this then you will need to have space for 1000000 stack frames while with divide-and-conquer you need space for only 14 frames. The following examples show how to rewrite a simple recursion to “divide-and-conquer” recursion: Here is an example of simple recursion:
  
  <xsl:template name="Count">
    <xsl:param name="current-idx" select="0"/>
    <xsl:param name="stop" />
  
    <xsl:value-of select="concat($current-idx, '|')"/>
  
    <xsl:if test="$current-idx &lt; $stop">
      <xsl:call-template name="Count">
        <xsl:with-param name="current-idx" select="$current-idx + 1" />
        <xsl:with-param name="stop" select="$stop" />
      </xsl:call-template>
    </xsl:if>
  </xsl:template>
  
  and here is the same template rewritten using divide-and-conquer approach:
  
  <xsl:template name="Count">
    <xsl:param name="current-idx" select="0" />
    <xsl:param name="stop" />
  
    <xsl:choose>
      <xsl:when test="$current-idx = $stop">
      <xsl:value-of select="concat($current-idx, '|')"/>
      </xsl:when>
      <xsl:otherwise>
        <xsl:variable name="split" select="$current-idx + floor(($stop - $current-idx) div 2)" />
        <xsl:call-template name="Count">
          <xsl:with-param name="current-idx" select="$current-idx" />
          <xsl:with-param name="stop" select="$split" />
        </xsl:call-template>
        <xsl:call-template name="Count">
          <xsl:with-param name="current-idx" select="$split + 1" />
          <xsl:with-param name="stop" select="$stop" />
        </xsl:call-template>
      </xsl:otherwise>
    </xsl:choose>
  </xsl:template>
  
• With the simple recursion I could not count even to 8000 (AMD64 machine, 1MB stack size) before getting StackOverflowException while with the divide-and-conquer version I easily got to 100000000. This does make a difference.

Obviously to work around this problem you can try increasing the stack size for the thread the transformation is running on but again – are you really sure you want to do this?

Pawel Kadluczka

• You need to query the document with a couple of XPath expressions or transform it with an Xslt file but the document is too big to be even loaded (the rule of thumb is that an Xml document needs up to 5 times memory of its size on the disk). When you try to load the document you get OutOfMemoryException and that’s about where your Xml processing ends.
• You are able to load the document but all the queries or transformations are sloooow (and I assume it’s not because the queries or Xslt stylesheets are poorly written – if you are not sure see Effective Xml Part 3)

These are problems indeed but there is a good chance they are solvable. First, take a look at the structure of the Xml in the source Xml. Then look at the XPath expressions or Xslt stylesheet. How much information from the source Xml are you actually using? Probably the bigger the file is and the more complex its structure the less data you are actually using. So, if you don’t actually use some data what’s the point of even trying loading it? Filter this data out. You can do it in a streaming fashion. Instead of using the XmlReader from the Xml API implement your own which will report the stuff you really need and ignore all you don’t really need (i.e. project). Depending on how much you need you can save a lot. Now you document can fit in the memory and the queries or transformations will be faster – they don’t need process nodes or attributes that are never being used. If you don’t feel like writing your own reader you can try using XPathReader http://msdn.microsoft.com/en-us/library/ms950778.aspx (note that the article is aged and may be using some old APIs but the basic idea is the same).

If the above steps don’t help you may try splitting your one big task to a few smaller tasks you can run sequentially. Doing this will hopefully enable you to achieve what your goal.

Pawel Kadluczka

Indeed, depending on how you use XslCompiledTransform API your transformations can be really fast or not-that-fast (to say the least). The key to understanding where this difference comes from is to understan what XslCompiledTransform.Load() method actually does. The name of the method indicates that it is just used to load Xslt stylesheets. In reality the method does much more than this. It not only loads the Xslt stylesheet but it also compiles it to IL (Intermediate Language). Yes, after the stylesheet has been “loaded” somewhere there in memory is the real code built based on the provided stylesheet. Generating this code (i.e. “loading” the stylesheet) is costly but it allows for fast transformations – when you start a transformation in your app it no longer deals with the stylesheet, it just invokes the code the Xslt stylesheet was compiled to.

The transformation itself is a separate step (you invoke it by calling XslCompilledTransfom.Transform() method). It means that the code generated during the load phase is kept somewhere in the guts of the system waiting to be invoked. Unfortunately if the XslCompiledTransform instance used to load the Xslt stylesheet is gone the compiled code is gone as well and you need to load (so, compile) the stylesheet again to be able to perform a transformation. The conclusion is simple – to have fast transformations you need load the Xslt stylesheet once and reuse the object for further transformations. Otherwise (i.e. if you load the same stylesheet repeatedly) you will take the performance hit caused by loading (compilation) the stylesheet each time instead of only once.

But actually you can do even better... Since Xslt stylesheets are compiled to IL like for instance C# programs why not compile it beforehand and avoid the hit related to compilation at runtime at all? It is actually possible. There is this tool shipped with Visual Studio SDK called xsltc (xslt compiler) that does exactly this. It takes an Xslt stylesheet, compiles it and saves the result on a disk as an assembly. Now you can add a reference to the assembly in your project and invoke the transformation as you would invoke any other function from a referenced assembly. You should know however that xsltc has a few limitations. The biggest one is around paths – if you are using document() function the compiled stylesheets may not work correctly if you deploy your application to a different machine. You can find more information about xsltc in the MSDN: http://msdn.microsoft.com/en-us/library/bb399405.aspx

As far as the performance of transformations is concerned this one should be obvious… Use non-debug stylesheet versions in production environment. XslCompiledTransform constructor takes a flag called: enableDebug. If the flag is set to true you are able to debug your stylesheet in Visual Studio. It’s a great feature but as you can expect it does not come for free. When a stylesheet is compiled in the debug mode not only there is no optimization to the compiled code happening but also the compiler has to emit additional instructions to make the debugger happy. In the non-debug mode however the code being generated is heavily optimized – unused code is removed completely, expressions that can be calculated beforehand are converted to literals/constants at compile time, no unnecessary from execution point of view instructions are injected etc. Another important reason to not use debug mode in production is that when stylesheets are compiled debug mode XslCompiledStylesheet will create a dynamic assembly each time a stylesheet is loaded (this is necessary to be able to support debugging). Such assemblies cannot be unloaded and may result in OutOfMemory exceptions. So, if you want to make your transformations fast and reliable don’t load stylesheets in the debug mode when running in the production environment. The easiest way to not to have to remember about changing the enableDebug flag is to couple it with build version (you are not running Debug version of your assemblies in production environment, are you?). If you build a Debug version of your app the enableDebug flag is true, if you build a Release version enableDebug flag is false (use #if DEBUG compiler directive to achieve this).

Follow good coding practices. Might sound weird but really, not doing this can kill the performance of you transformations. The problem here is that under certain circumstances JITer (Just in Time compiler) stops optimizing the assembly code generated from the IL code the stylesheet was compiled to. This happens for instance when a method is too big or there is too many local variables. There is no need to be scared. It’s not easy to hit this issue. Stylesheets with templates (each template is compiled to a separate method) having a few hundred or even a thousand of lines should be fine (although a function consisting of 1000 lines feel too big from a “good coding practices” standpoint). As far as local variables are considered - it is not only about variables declared with xsl:variable instruction. Think about XPath – each step in the XPath expression is actually a loop and as such it needs a variable to iterate on. Again, even though the Xslt compiler (i.e. XslCompiledTransform) creates a lot of variables under the cover it is not easy to hit the problem. You would have to have thousands of them to see it. Still some people see it. And it is usually the combinations of both of the problems. A stylesheet contains a huge template (in the most common case the stylesheet is huge (e.g. 3 MB) and consists of just one template) – which results in a big method. Since the template is huge it contains a lot of XPath expressions – which results in a big number of local variables. As a result JITer gives up on any optimizations to the generated assembly code and transformations take ages. The solution is simple. Refactor the code. Why is the stylesheet so big? Probably because there is a lot of the same code copied all over the place (honestly, even though Xslt is verbose it’s not easy to come up with a well refactored stylesheet whose size is 3 MB – it’s 3145728 bytes which gives roughly 20000 lines (80 characters per line, 2 bytes per character), most likely 30000 lines – Copy/Paste must have been in use) – move the common code to a separate templates. Change this one huge xsl:choose statement to separate templates and invoke them using xsl:apply-templates instructions from appropriate places in your code. Do yourself and the person who will be maintaining the stylesheet when you are on vacation a favor. And make the transformation fast at the same time.

Pawel Kadluczka

1. // (descendant-or-self axis)

This is a very common pattern that very often leads to serious performance problems. The way it works is that it flattens the whole subtree (the most common usage I saw is flattening the whole xml document) and then it looks for the specified elements. Now in the .NET Framework there aren’t any specific optimizations for this patterns and using it *is costly*. I tried to figure out in what scenarios using // is really useful or necessary and the only real case where I found it useful was when the Xml was designed to have elements with the same name on different levels (e.g. recursive xml document describing the file system where <folder> element can have <folder> child elements). Other than that I could not really find any usage that could not be replaced with a more efficient counterpart. Usually being as specific as possible in your query helps (and is enough). Why do people use // then?

• “It’s easy” - I agree but for me it is not an argument. Sure it’s the best when fast performing apps don’t need a lot of effort to write but it is rarely the case. Put some extra effort and you will see tangible results.
• “If I use // it works otherwise it does not” – check your XPath expression. Go step by step and see if you don’t have any typos. Finally look for namespaces (this is the most common thing I noticed for this kind of usage – there are elements in namespaces so “nothing but //*[local-name() = ‘{put-element-name-here}’] works”. Spend a day with Xml namespaces. I know it is not an easy stuff but understanding Xml namespaces will help you a lot if work with Xml.)
• “I don’t know the structure of the Xml document” – now you are in trouble. If you don’t know the structure of the Xml documents you are processing how do you know you will not capture some extra elements with //? Using // in this kind of situation feels like introducing bugs.
• “The structure of my document changes very often” – (this is pretty similar to the one above) you should be updating you XPath expressions accordingly and consciously. Otherwise you may start processing nodes you did not really mean to process or, if some elements were removed entirely, your application will continue to use expensive query just to find out that there is nothing to process.

Yes, I know that many books, articles or blogs that teach Xslt use //. I suppose the reason there is that when you start learning Xslt you probably don’t know what the XPath is and // is the simplest thing that works. Unfortunately even after people learned XPath they continue to use // all over the place and complain that Xml/Xslt/XPath is slow (real story: I was refactoring a stylesheet that was slow – the transformation took 2 minutes and it was a web application. Just getting rid of all // (none of them was necessary) the transformation time decreased to 5 seconds).

2. Absolute XPath Expressions Everywhere

While sometimes it may be beneficial to use an absolute XPath expression (i.e. starting from the document element - /) it is not usually the case. Yet I saw Xslt stylesheets that were using only absolute XPath expressions. This is not only costly (though not as costly as //) but in a lot of cases it is just plainly wrong. If you are positioned on an element and you want to process all the child elements of this element using an absolute path will work only if the element you are positioned on does not have any sibling elements with the same name. Otherwise you will start processing all the child elements of all the siblings with the same name as the element you are positioned on.

3. Filter as Close as You Can

Take a look at the following expression: a/b/c[../../@id = 3]. What is happening here? We drill into the tree only to go up to check the condition on one of the ancestor elements. As a result we may process hundreds of <b> and <c> elements without any reason (because the condition is not satisfied). In addition the expression is not really readable. How about this expression: a[@id = 3]/b/c? The result should be the same as in the case above but it can be much faster because now we will not process elements we are not really interested in. It is also much more readable – I don’t need to virtually traverse the Xml document to be able to tell what element the condition applies to.

4. Don’t call document() function in a loop

document() function has to go and access an external file or a network resource. Accessing file system (let alone network resource) is much more expensive than accessing memory. So instead of doing this in a loop (by loop I mean either xsl:for-each or xsl:template invoked more than once) just select what you really need once, store it in a variable and use the variable instead of document() method.

5. Learn Axes and Use Axes

XPath has 13 different axes. From what I noticed people don’t know about XPath axes although they use them almost in each XPath expression they write. The reason for this is that the default axis is child axis and can be omitted. As a result /child::a/child::b (child:: denotes child axis) becomes /a/b. Similarly . is a shortcut for self::node() and .. is a shortcut for parent::node() (so, parent::node()/child::b becomes ../b). With these shortcuts (and // which is another shortcut – this time for /descendant-or-self::node()/ axis and which you should not be using without a good reason) people are able to address most of their needs without even having to know about axes. It’s more like “this is how XPath works” rather than “I really want to navigate the tree this way” (although in most cases the result of these two will be pretty much the same).

Here is an example – I want to access the next element on the same level that the element I am positioned on. It’s pretty easy with the following-sibling axis: following-sibling::*[1]. Without using the following-sibling axis the expression can get complicated – you would probably have to capture the current position in a variable, go to the parent element and then address the element you are interested in using an index calculated based on the variable.

If you happen to use any of the above patterns or you think you are not using the right axes take a closer look at your stylesheets and think whether you could improve things and give a nice boost to your queries or transformations. Have I mentioned that you should avoid using //?

Pawel Kadluczka

Managed Xml API contains a few different APIs that allow to start working with Xml documents. These are:

• XmlReader
• XPathDocument
• XmlDocument
• XDocument/XElement (LINQ to Xml)

The reason why there are that many APIs is that each of these can be very effective when used in some scenarios while cannot be used or is less effective in other scenarios. Let’s take a look at these APIs and scenarios where they shine.

XmlReader – as per MSDN “provides fast, non-cached, forward-only access to XML data”.  In general XmlReader reads data from the source stream, ensures that the data is a valid Xml and reports what it read. XmlReader is typically controlled by some code that tells the reader what to read (ReadXXX() methods) or what to skip (MoveToXXX()/Skip() methods). This is the responsibility of the controlling code to process (or cache) the results reported by the XmlReader since the XmlReader will “forget” what it read once moved to the next node.

Note: XmlReader is the lowest level API in the whole .NET Framework that allows reading Xml documents. This means that *any* class in the whole .NET Framework that needs to read Xml documents is – either explicitly or implicitly – using XmlReader under the cover.

If you decide to use XmlReader remember to create the reader using XmlReader.Create() factory method which will create the right reader according to the provided  XmlReaderSettings. Avoid using XmlTextReader. It contains quite a few bugs that could not be fixed without breaking existing applications already using it.

Typical scenarios:

1. Processing huge files – since XmlReader does not cache any data so it can be used for processing files that would not fit into memory.
2. Xsd schema validation – if you just need to validate an Xml document against schema without any further processing using XmlReader is the most effective way.
3. You need to cache the data using your own object model - e.g. you read an Atom feed and rather with dealing with Xml elements and attributes you need to deal with Author, Contributor and Link instances your application uses.
4. You don’t care about the whole document – e.g. for some reason you just need to check what namespace the root Xml element is in. Why paying the price of loading the whole document just to check this one thing? You can just start reading the document with XmlReader, move to the root element, check the namespace and dispose the XmlReader.
5. Simple transformations – along with XmlWriter you can use XmlReader to do simple transformations (like filtering) where you read an Xml documents with XmlReader and use XmlWriter to write the output Xml document.

Scenarios where using XmlReader is not effective or impossible:

1. Caching - you need to random access to the data – the data could but did not have to be read yet.
2. Complex processing – using XmlReader API is not very easy and you may get to the point when you trade the performance gains off for readability and maintainability of the code.

XPathDocument – is an Xml cache optimized for querying Xml documents. It’s a cache so the whole Xml document has to be read (yes, it is using the XmlReader to do this) before it can be queried. For better query performance and smaller memory footprint the XPathDocument does not allow for any modifications to the cached document.

Typical scenarios:

1. You need to query an Xml document with XPath – note that if you have a relatively simple XPath expression(s) you may be able to achieve the same results with XmlReader.
2. You need to transform an Xml document with Xslt – Xslt transformations don’t need write access to the source document but usually query the source document a lot. XPathDocument is the best choice for Xslt processing.

Scenarios where using XPathDocument is not effective or impossible:

1. You need to be able to modify the loaded Xml document.

XmlDocument – is an API modeled on Xml DOM (Document Object Model). Similarly to the XPathDocument the XmlDocument is a cache, so when working with Xml data from an external source the whole Xml document has to be read first. Unlike the XPathDocument however the cached document can be modified. With XmlDocument it is also possible to build Xml documents programmatically from scratch rather than load them from external sources. The price to pay for this flexibility is worse query performance and bigger memory footprint when comparing to XPathDocument.

Typical scenarios:

1. You need to build your Xml document programmatically and do additional processing – note that if you just need to persist the document you have built (so, there is no further processing  like querying or transformations after the document has been built) using just XmlWriter will be much more effective.
2. You need to load and modify an Xml document and do additional processing – again if there is no additional processing you usually will be better off (performance-wise) if you use XmlReader/XmlWriter tandem.

Scenarios where using XmlDocument is not effective:

1. You use Xml document just to do XPath queries or Xslt transformations – use XPathDocument instead.
2. You use the XmlDocument API just to create the Xml document and save it – use XmlWriter instead.
3. You use the XmlDocument API just to modify the loaded Xml document and save it – for simple cases consider using XmlWriter and XmlWriter to achieve the same goal

XDocument/XElement et al. (LINQ to Xml) – a new XML API added to the .NET Framework in version 3.5 along with a new way of querying – Language Integrated Query (LINQ). With Linq to Xml APIs you can achieve most of what you can achieve with XmlDocument (e.g. build and modify Xml documents, validate Xml documents against Xsd, do Xslt transformations, query with XPath etc.) but in a much easier and lighter way. You have also a new way of querying Xml documents – LINQ queries. In new projects you should prefer LINQ to Xml APIs over XmlDocument.

Although XDocument needs to cache the entire Xml most LINQ queries work with just XElments (or XAttributes etc.) or to be more precise with IEnumerable<T> where T is XElement (or XAttribute etc.). Due to the nature of IEnumerable (deferred execution) it is possible to combine XmlReader and IEnumerable in and be able to query Xml documents without having to load the whole document to memory first. See this blog entry for more details: http://blogs.msdn.com/b/xmlteam/archive/2007/03/24/streaming-with-linq-to-xml-part-2.aspx

Typical scenarios:

1. You need to build your document programmatically and do additional processing.
2. You need to load and modify an Xml document and do additional processing.
3. You want to be able to query an Xml document with LINQ.
4. You need to do simple ad hoc transformations – while you can use Xslt to transform Xml documents you can also do transformations using LINQ to Xml APIs which is much lighter than Xslt.

Scenarios where using XmlDocument is not effective:

1. You use the XDocument/XElement API just to create the Xml document and save it – use XmlWriter instead.
2. You use the XDocument/XElement API just to modify the loaded Xml document and save it – for simple cases consider using XmlWriter and XmlWriter to achieve the same goal.
3. You need to do a lot of XPath queries on the document – querying XDocuments with XPath is slower than querying XDocuments with LINQ. Consider replacing XPath queries with LINQ counterparts. If you don’t modify the document at all – you may consider using XPathDocument (however see the section about mixing different APIs below).

One scenario where you may want to use XPath with XDocument however is when you generate queries dynamically. It’s not easy to generate Linq queries on the fly and using XPath in this scenario is probably the best solution if your application is using XDocument/XElement.

Mixing LINQ to Xml with other Xml APIs

There is no magic cast that allows converting XDocument/XElement to XPathDocument or XmlDocument. “Converting” actually means building the whole XmlDocument structure from scratch based on the source XDocument/XElement. It is a costly operation and doing this continuously or for bigger documents can cause performance problems. As far as perf is considered it is usually better to stick to XmlDocument and/or XPathDocument in legacy applications already using these APIs while use LINQ to Xml in new apps.

Writing Xml Documents

The XmlWriter is the lowest level Xml API used to write Xml documents. Any other .NET Framework API persisting Xml documents is using this API. If you just need to write an Xml document this is the fastest way to do it. If you need to write a document that has already been cached (i.e. you already have XmlDocument or XDocument instance in hand) you don’t need to do anything special.

Pawel Kadluczka

(Update - This blog post was updated on 07/23/2010 to account for XP SP2’s" “End-of-Support.” XP SP2’s support ended on 07/13/2010. Please see http://support.microsoft.com/gp/lifean46 for further clarification.)

First things first, we—the XML team—would like to apologize for the confusion that the shift from MSXML6 as an out-of-band (OOB) to in-band component has caused. We hope this post will clarify that change and in turn aid you in building/maintaining your MSXML6 dependent applications.

In Microsoft lingo, OOB describes a component that is installed on top of Windows. I.e. A clean install of the Windows Operating System (OS) does not contain the component and thus an OOB installer must be used to gain the functionality desired. In the case of MSXML6, the OOB install was originally accomplished via an MSI but more recently KB<number>.exes—which are merely wrappers for the underlying MSXML6.MSI—are how we are distributing the OOB. For example, the latest OOB installed MSXML6 was released on 11/23/2009 in KB973687.

In the past several years, we’ve worked to move MSXML6 in-band for all supported releases of Windows. This began with Vista RTM and has remained the practice for all OS releases since then. Specifically, MSXML6 is in-band for XP SP3, Vista and Windows 7 . It should also be noted that the Vista and Windows 7 Server counterparts also contain in-band MSXML6. I.e. Windows Server 2008 and Windows Server 2008 R2 respectively. One caveat, those that are using Windows Server 2003 will still need to install MSXML6 via MSI/KB<number>.exe wrapped MSIs.

So what does all of this mean for you? If your MSXML6 dependent application is supported on XP SP2 and Windows Server 2003, you’ll need to install the OOB package of MSXML6. For all other OSes called out above, your MSXML6 dependent application needn’t worry about installing MSXML6.

The XML Team

PS As always, please post comments/help requests to our forum here….http://social.msdn.microsoft.com/Forums/en/msxml/threads
PPS Table above showing where MSXML6 is in-band vs. OOB. Note that “All SPs” means that MSXML6 is in-band starting with RTM (Release to Manufacturing) of the OS and therefore also in-band for all subsequent SPs (Service Packs)

Definitions

For clarity, in the discussion below, it helps if we define a few terms.

Physical View: A Visual Studio editor supports different types of windows for editing documents, each known as a Physical View. One example of a physical view is a code editor window, another is a forms designer.

Logical View: Each physical view could be enumerated further to have more classification. A Logical View can have code, design, debug, and text views, and the editor could support these views with different physical views. For instance the WPF editor supports both WPF Designer and the Code view, the design and code logical views of this editor. (more information available at: http://bit.ly/cE1EUP)

Visual Studio Registry Hive: Visual Studio keeps most of the settings under registry. The root of the VS hive for 32 bit systems is HKLM\SOFTWARE\Microsoft\VisualStudio\10.0. {VSRoot} will be used in this document to reference this hive.

Visual Studio Editors

An editor needs to get elements and features of a language.  One example is formatting information.  A Language Service is a Visual Studio service that provides this information for a specific language. A language service is needed A language service can provide information to multiple editors. For more information on Language Services you may refer to http://bit.ly/bisnEE.

Editor Choosing when Opening File

The editor choosing on Visual Studio is done by file extensions. If you have a new file extension that you want to open in a language service, you’ll need to create a new entry under {VSRoot}\Editors. This entry consists of properties such as the display name and the package GUID. Underneath this entry there are following keys:

• {VSRoot}\Editors\{Your Editor GUID}\LogicalViews
• {VSRoot}\Editors\{Your Editor GUID}\Extensions

The {VSRoot}\Editors\{GUID}\LogicalViews contains logical views that are represented by a GUID:

These logical views represent which views this editor supports. Visual Studio queries the registered editors when there is a need to change the logical view. The query happens when user starts debugging, stops debugging, clicks on Design View at the View menu, or clicks on an error at the error list. If a document is already open within one view, Visual Studio could still query the editor for the same logical view.

The {VSRoot}\Editors\{Your Editor GUID}\Extensions registry key holds a list of file extensions and DWORD values to prioritize the editor against the other editors in Visual Studio for that specific file extension. A specific editor is chosen to open a document when it has the highest priority among the editors that are both registered for the document’s file extension and registered to support the desired logical view. However, if the editor rejects the request, then Visual Studio will query the proceeding prior editor until an editor is found. For instance, in Visual Studio 2010, the xml extension is mapped to XmlEditor under {VSRoot}\Editors\{fa3cd31e-987b-443a-9b81-186104e8dac1} with priority of 42. XmlEditor is the second at the priority list therefore would be queried if the most prior editor rejects the document open query.

To sum up this section, Visual Studio have file extension based logic that assigns a file extension to an editor. This is done through {VSRoot}\Editors for prioritizing each editor with a file extension. Each editor’s file extension has a priority and the editor with highest priority extension will be called first to open the file.

The need for XmlChooser

In most cases, the file extensions uniquely define what the file contents are. In XML world however, file extensions are less important. For example, the .xaml is used for Silverlight, Workflows, WPF … and each of these define a different editor. By just looking the extension we cannot decide which editor this file belongs to.

The major identifiers used in XML are the XML namespaces, especially, the root namespace. Thus, the real choosing logic should be based on the XML root namespace.

The IVsEditorFactoryChooser

In Visual Studio 10.0, the IVsEditorFactoryChooser interface is added to enable registered editors to implement an editor choosing logic so that these editors are no longer a real Visual Studio Editor, but rather they are editor choosers. If these Editor Choosers are registered for the specific file extension, VisualStudio will query for this extension, and if implemented Visual Studio will forward the result of the choosing to the appropriate editor. An editor chooser that implements IVsEditorFactoryChooser, can either return another editor, or just returns “cannot open this file” to force VS to try other editors in the priority list. MSDN article of IVsEditorFactory chooser can be found here http://bit.ly/c8Op5w.

XmlChooser is the implementation of IVsEditorFactoryChooser. XmlChooser is designed to handle open file requests for XML. XmlChooser is registered in the Visual Studio Registry Hive as an editor with a priority of 0x21 (43 decimal).  Since this is the highest priority “Editor”, the XmlChooser will have priority over any other XML based editor registration.

Registering for XmlChooser

If you have a file type that’s based on XML which has following properties:

• has a common file extension and
• the identifier for that file extension is the root namespace,

And if you want to register a new editor for this file then you should register the file extension not just only through the editors/projects registry hives that’s mentioned above, but also through XmlChooserFactory hive.

If your editor’s file extension is unique, then there is no need to be part of XmlChooser.

Pre-requisites

We are assuming you already have this editor working with Visual Studio. This means that you should have registered your editor at {VSRoot}\Editors\{EditorGuid}, including specifying the the extension you want to register, and a priority value for your editor a DWORD value higher than 0x21 at {VSRoot}\ Editors\{YourEditorGuid}\Extensions. (The reason why you would want to have a priority value higher than 0x21 is that XmlChooser is registered for all extensions at 0x21, if you have a value lower than 0x21 and if your document is an XML based file, then XMLEditor will open the document.)

At this state, your editor should be functioning without interference of XmlChooser.

Registry changes to register to the XmlChooser

We will need to update two registry locations to have Visual Studio to point to XmlChooser for your editor with your file extension.

1. Update Projects hive to change the EditorFactoryNotify
2. Add your file extension to the Editors\XmlChooser’s hive

1. Update Projects hive to change the EditorFactoryNotify

Each Project in Visual Studio keeps a list of file extensions and Editor GUIDs to associate an extension with an Editor. In order to associate a file extension to an editor in Visual Studio, you need to add/modify each project’s file extensions registry entry. To associate your file extension with XmlChooser the following update to the registry is required

{VSRoot}\Projects\{ProjectGuid}\FileExtensions\ {.YourFileExtension} should contain EditorFactoryNotify key that should point to XmlChooser’s GUID {32CC8DFA-2D70-49b2-94CD-22D57349B778}

This will force the project system to point to XmlChooser when the file needs to be opened.

2. Add your file extension to the Editors\XmlChooser’s hive

XmlChooser at Visual Studio Editors registry hive contains the list of extensions, with priorities. If your file extension is already registered with other editors, you should add your file extension to the XmlChooser’s Editors hive with the highest priority. As XmlChooser’s guid is 32CC8DFA-2D70-49b2-94CD-22D57349B778, the following location needs to be updated:

{VSRoot}\Editors\{32CC8DFA-2D70-49b2-94CD-22D57349B778}\Extensions should contain yourFileExtension with DWORD priority value. As we mentioned above, the value of this key must be higher than the value at {VSRoot}\Editors\{YourEditorGuid}\Extensions at Pre-requisites section.

In case that you are adding an extension that’s already being handled by XmlChooser such as .xaml, your editor’s file extension priority that we mentioned at Pre-requisites section must be lower than XmlChooser to allow XmlChooser to take priority over your editor.

XmlChooserFactory

The functionality of hierarchical choosing at XmlChooserFactory is handled through the registry. The following tree structure handles the association between registered file extensions, logical views, and the editors.

This hive is at {VSRoot}\XmlChooserFactory typical structure is as follows:

The keys at the root node XmlChooserFactory is for settings for XmlEditor itself. Users of this hive are not expected to change this node.

XmlChooserFactory have child nodes (FileTypeA, FileTypeB… in the example above). Each child node’s name is just a human readable string that has no functional significance. You may pick any unique name for your editor. Each child node can have other child nodes (see the FileTypeC) which define a node that’s more specific (limiting) than the parent node. All settings are inherited to the child node from parent node.

Each child node has the following entries:

• Extension=REG_SZ:{YourFileExtension}: The file type’s file extension. (Optional)
• Namespace= REG_SZ:{YourRootNamespace}: The file type’s root namespace. (Optional)
• Match= REG_SZ:“both”: If this entry is specified there could be a match if both the Extension and Namespace matches if this key does not exist, there is a match if any of the Extension and Namespace matches. (Optional)
•  IsDataSet=dword:00000001: This is special instruction to sniff DataSet designer’s XSD files as their Extension and Namespace is not unique enough to distinguish them from a normal XSD designer. This can be considered internal. (Optional)
• {7651A700-06E5-11D1-8EBD-00A0C90F26EA}=REG_SZ:{ARegisteredEditorGuid}
• {7651A701-06E5-11D1-8EBD-00A0C90F26EA}=REG_SZ:{ARegisteredEditorGuid}
• {7651A702-06E5-11D1-8EBD-00A0C90F26EA}=REG_SZ:{ARegisteredEditorGuid}
• {7651A703-06E5-11D1-8EBD-00A0C90F26EA}=REG_SZ:{ARegisteredEditorGuid}:  
  For each logical view that your scenarios support you should associate the logical view with an editor that’s registered at {VSRoot}\Editors hive. If the associated editor GUID is not found on the {VSRoot}\Editors hive, the result will be defaulted to XmlEditor. (Optional)
• DefaultLogicalView={ALogicalViewGuid}: DefaultLogicalView is taken into consideration when the open file request has Primary Logical View (see http://bit.ly/cE1EUP). ALogicalViewGuid should be replaced with one of the following values: {7651A700-06E5-11D1-8EBD-00A0C90F26EA}, {7651A701-06E5-11D1-8EBD-00A0C90F26EA}, {7651A702-06E5-11D1-8EBD-00A0C90F26EA}, {7651A703-06E5-11D1-8EBD-00A0C90F26EA}
• XmlEditorBlockSxS={ARegisteredEditorGuid}: If you want your editor not to be side by side with XmlEditor. (Optional)
  
  You may want to set this key if your editor does not support side by side editing with XmlEditor. If this key is set, when the user tries to open a document in XmlEditor that’s already open by the editor that’s specified by ARegisteredEditorGuid, XmlEditor will ask the user to close that editor.
  
  If this is the only functionality is needed, you may also create a node under XmlChooserFactory, with just this key.

As noted above, each node has definitions to create the relation between a file extension, a logical view, and an editor. A relation can be specified if a file type fits into one or many of the following:

• have a namespace that’s unique to the file type,
• have an extension that’s unique to the file type, 
• both of extension and namespace could uniquely identify the file type

Extension, Namespace, and Match values will be used to test if a candidate file type is a match. Once there is a match, the logical views – editors associations and the DefaultLogicalView key is used to resolve the editor to be opened.

Example

An example for XmlChooserFactory are as follows:

/* The following blocks Editor with Guid CCCCCCCC-DDDD-EEEE-FFFF-BBBBBBBBBBBB to be side by side with Xml Editor. */

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\10.0\XmlChooserFactory\EditorOne]
"XmlEditorBlockSxS"="{CCCCCCCC-DDDD-EEEE-FFFF-BBBBBBBBBBBB}"

/*a file with xaml extension AND http://schemas.microsoft.com/example/2009 namespace should be opened in XmlEditor (FA3CD31E-987B-443A-9B81-186104E8DAC1) for debugging and code logical views, The editor with GUID CCCCCCCC-DDDD-EEEE-FFFF-CCCCCCCCCCCC for Designer, and the editor with guid CCCCCCCC-DDDD-EEEE-FFFF-DDDDDDDDDDDD for text view (actually text view generally is equal to the code view). */

 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\10.0\XmlChooserFactory\MyEditor]
"Extension"="xaml"
"Match"="both"
"Namespace"=http://schemas.microsoft.com/example/2009
"DefaultLogicalView"="{7651A702-06E5-11D1-8EBD-00A0C90F26EA}"
"{7651A700-06E5-11D1-8EBD-00A0C90F26EA}"="{FA3CD31E-987B-443A-9B81-186104E8DAC1}"
"{7651A701-06E5-11D1-8EBD-00A0C90F26EA}"="{FA3CD31E-987B-443A-9B81-186104E8DAC1}"
"{7651A702-06E5-11D1-8EBD-00A0C90F26EA}"="{CCCCCCCC-DDDD-EEEE-FFFF-CCCCCCCCCCCC}"
"{7651A703-06E5-11D1-8EBD-00A0C90F26EA}"="{CCCCCCCC-DDDD-EEEE-FFFF-DDDDDDDDDDDD}"

Conclusion

When a file with a unique extension is bound to an editor with its supported logical views, the editor registration is rather straight forward. However when there are overloads to files things could get complex pretty rapidly. We hope this document helped you understand the issues and solutions.

Visual Studio handles the problem of which editor to choose through the {VSRoot}\Editors and {VSRoot}\Projects hives. Each project registers extensions, and each editors’ prioritized file extensions define the order that Visual Studio tries to open a file with that editor. It’s up to the editor to reject the file, and when that happens, next registered editor is tested to open the file.

However this mechanism is not enough when there are many editors defined for same file extension.   To solve this problem, the IVsEditorFactoryChooser interfacemay be implemented.  Implementations of this interface allows programmatic determination of which editor to use. 

In Visual Studio 10.0 we introduced XmlChooser that implements IVsEditorFactoryChooser. We created a hierarchy in registry so that our customers/partners who have XML based files could hook up their editors. XmlChooser takes into consideration the file’s extension and root namespace of the document.  Additionally, it allows logical view-editor pairings and default logical views to be defined.

The XmlChooser also helps to define blocking side by side experience with other editors, where no other editor is allowed to have the file open when XML Editor opens the file.

Yours truly,

Sinan Usakli
Software Designer Engineer
Data Modeling Group
Microsoft Corp

You may ask why MSXML6.0 is being mentioned here and what relationship exists between two versions. Please read below for historical context:

MSXML4.0 was released to the web in April 2001 to provide a number of new features (e.g. XSD, SOM, Side-by-Side Functionality) as well as great performance improvement (e.g. XSLT Performance) . The latest version, MSXML 4.0 SP3, was released in March 2009 and is a replacement for all previous releases of MSXML4.0. i.e. MSXML4.0 RTM/SP1/SP2. Once MSXML4.0 SP2 support expires on 4/13/2010, MSXML 4.0 SP3 will become the only supported version of MSXML4.0. Support for MSXML4.0 SP3 will be limited to security fixes only and there is no plan for future service packs.

MSXML 6.0 was released in July 2006 to provide an upgrade path for those using previous MSXML versions. MSXML 6.0 represents the key Microsoft native core XML stack in the COM/scripting environment and provides the best security, performance, reliability, and W3C conformance. Unlike MSXML4.0, MSXML6.0 ships with most supported Windows OSes, thus relieving developers of the headache of redistributing the MSXML6.0 on more recent OSes. I.e. as long as your clients are running Windows XP SP3, Vista RTM/SP1/SP2, Windows 7, there’s no need to install MSXML6.0. For those running Windows 2003, please download the package from the Microsoft Download Center.

We strongly encourage our customers to migrate applications to MSXML 6.0 as soon as possible as this is our most supported version. If you are building new application please use MSXML 6.0. In closing, we are quite keen on understanding how we can provide our customers the best possible migration path. If you have any feedback please do post it on MSXML forum where we would love to hear from you!

MSXML team