• What's New in MSXML 6.0

• What's New in MSXML 5.0 for Microsoft Office Applications

• What's New in MSXML 4.0

• What's New in MSXML 3.0

MSXML 6.0 shipped with SQL Server 2005. It also shipped as a Web release. The following is a high-level summary of features that were introduced with MSXML 6.0.

• Security

  A number of enhancements have been made to MSXML 6.0 to eliminate security threats. Additionally, some features that are insecure, such as DTDs and inline schemas, have been turned off by default. For more information, see MSXML Security Overview.

• XDR Schema Support Removed

  XML Data Reduced (XDR) schema support has been removed. For more information, see Removal of XDR Schema Support.

• Improvements in XSD Standards Compliance

  MSXML 6.0 has improved XSD schema standards compliance. For more information, see Improvements in XSD Standards Compliance.

• Improvements in Schema Cache Behavior

  MSXML 6.0 has changed the behavior of the XSD schema cache. The new version is less ambiguous when there are name collisions. For more information, see Improvements in Schema Cache Behavior.

• XML Digital Signature Removed

  MSXML 6.0 removed support for XML digital signatures. For more information, see XML Digital Signatures.

• Normalization of Attribute Values

  MSXML 6.0 SP2 added support for normalization of attribute values per the World Wide Web Consortium (W3C) specifications for XML 1.0.

Other Changes in MSXML 6.0

MSXML 5.0 for Microsoft Office Applications first shipped with Microsoft Office 2003 and is designed for use specifically with applications targeting the Microsoft Office family of products. The following is a high-level summary of features that were introduced with MSXML 5.0 for Microsoft Office Applications.

• XML Digital Signature

  MSXML 5.0 for Microsoft Office Applications introduced support for XML digital signatures, allowing you to sign and verify XML data in DOM documents, DOM nodes, or SAX streams. For more information, see XML Digital Signatures.

• Validation of DOM Nodes

  In earlier versions of MSXML, only full DOM documents could be validated. MSXML 5.0 for Microsoft Office Applications now provides the ability to validate a single DOM node as an XML document fragment against the currently loaded DTD, schema, or schema collection. For more information, see the validateNode method.

• Import DOM Nodes

  MSXML 5.0 for Microsoft Office Applications provides the means to clone a node from one DOM document, so it can be added later into another DOM document using the appendChild method. For more information, see the importNode method.

• Additional Second-Level DOM Properties

  With MSXML 5.0 for Microsoft Office Applications, more second-level DOM properties have been introduced that enable you to use the setProperty and getProperty methods to more closely monitor or configure settings that affect XML parsing behavior. For more information, see Second-level DOM Properties.

• Modified Support for Handling Inline Schemas

  MSXML 5.0 for Microsoft Office Applications now includes new options in the DOM and SAX APIs that allow for support of inline XSD schemas.

The following is a high-level summary of features new to MSXML that were introduced with MSXML 4.0.

• Support for XML Schemas (XSD)

  MSXML 4.0 provides extensive support for the final World Wide Web Consortium (W3C) XML Schema (XSD) Recommendation. For example, you can validate XML data and documents against XML schemas (XSD) using either DOM or SAX programming models through the use of either external schema cache or through the xsi:schemaLocation or xsi:noNamespaceSchemaLocation attributes. Although MSXML 4.0 does not support XPath 2.0, MSXML 4.0 provides extension functions, permitted by standards, to support handling XSD types in XPath and XSLT.

  For more information, see XML Schemas (XSD) Reference.

• Support for the Schema Object Model (SOM)

  MSXML 4.0 also provides a way to reach schema information in validated documents using type discovery in SAX and the Schema Object Model (SOM) in DOM. In addition to this added support for the final XML Schema recommendation, MSXML continues to support XML-Data Reduced (XDR) and document type definition (DTD) validations.

  For more information, see the SOM section.

• Side-by-Side Functionality

  MSXML 4.0 supports Windows Side-by-Side (SxS) installation under Windows XP or Windows Server 2003. This means that when you install MSXML 4.0 under these qualified versions of Microsoft Windows, you have side-by-side access to other versions of MSXML. Potentially, SxS installation can also include support for running multiple released versions of MSXML 4.0 side by side under Windows. To do so, you will have to create a special application manifest, which will link your application to the specific version of MSXML 4.0. If you want to use MSXML in the same way as before, you don't have to do anything; MSXML installs in both global (as before) and side-by-side (new) mode on Windows XP and Windows Server 2003.

  For more information, see MSXML and Windows.

• Removal of Support for Replace Mode Installations

  Before MSXML 4.0, you could use replace mode to make the latest MSXML component simulate MSXML 2.0, which Internet Explorer 5.0 and 5.5 used for presenting XML when browsing. In some cases, a special utility, xmlinst.exe, manipulated the Microsoft Windows registry to achieve this effect.

  With MSXML 4.0, replace mode is no longer supported or required. MSXML 4.0 does not replace earlier versions of MSXML and cannot be used to substitute MSXML 2.0 for Internet Explorer. That means that if Internet Explorer is your default program to open XML files, and you double click on an XML document, Internet Explorer will not use MSXML 4.0 to show it.

  You can however, still programmatically call and use MSXML 4.0 as was possible with earlier versions of MSXML so that it is used to manipulate XML within an HTML page using script.

  For more information, see Initiate XSLT in a Script.

• Version-Independent ProgIDs Removed

  Version-independent ProgIDs were available in MSMXL and earlier releases and appeared such as the following when used in JScript code:

  var xmldoc = CreateActiveXObject("MSXML2.DOMDocument")

  or in Visual Basic code as:

  Dim xmldoc As New MSXML2.DOMDocument

  These types of version-independent ProgIDs are now removed with MSXML 4.0 and later versions. This guarantees that MSXML 4.0 and later versions of MSXML will not interfere with any versions of MSXML (2.0, 2.6, or 3.0) previously installed.

  If you use the previous examples in your code, you will not instantiate the MSXML 4.0 DOM, but instead the prior replace-mode versions of the MSXML parser (MSXML 3.0 or earlier depending on the version of Windows or other installed applications on the system that use MSXML).

  If you want to use MSXML 4.0, you must create a DOMDocument object in JScript like this:

  var xmldoc = CreateActiveXObject("MSXML2.DOMDocument.4.0")

  Accordingly, for C++ and Microsoft Visual Basic you will create "MSXML2.DOMDocument40". Similar changes will be necessary with all other MSXML objects in order to use the MSXML 4.0 version.

  So why was this support removed in MSXML 4.0 and later versions? The primary reason for this change was to improve the maintainability of MSXML-based code, which otherwise was highly error-prone when unexpected changes occurred in the environment. In actual field experience when deploying and supporting XML applications, version-independent ProgIDs were very convenient for a developer wishing to try out MSXML with little or no code change, but very risky for code running in production environments.

  For example, many were able to develop code that used the version-independent ProgIDs, and expect a specific version of MSXML 3.0 to be in place. If for any reason a system was later updated by a user, such as to install (or reinstall) Microsoft SQL Server 2000, they might unexpectedly find that they were using MSXML 2.6 instead of MSXML 3.0. Removing version-independent ProgIDs in MSXML 4.0 eliminates such instability, and improves MSXML as a server-side enterprise-grade component.

• Extended Support for Sequential XML Processing Architectures

  The ServerXMLHTTPRequest object, which was introduced in MSXML 3.0, provided reliable server-side HTTP access independent of WinInet. This server-side HTTP stack functionality is now included with the new WinHTTP 5.0 component, which is shipped and installed with MSXML 4.0. ServerXMLHTTPRequest provides only the front end to this component.

  MSXML 4.0 provides extended support for sequential XML processing architectures based on the SAX2 API. This includes:

  • Integration between the DOM and SAX parsing models

  • Ability to generate HTML output

  • Ability to plug the SAX content handler to the output of the XSLT processor

  • Tracking of namespace declarations

  You can now use the MXXMLWriter object to generate SAX events from a DOM tree. You can likewise build a DOM tree out of SAX events. This feature allows you to closely integrate DOM and SAX in your applications.

  A new object, MXHTMLWriter, enables you to output HTML using a stream of SAX events in much the same way that the <xsl:output> element in XSLT can generate HTML from a result tree. The new MXHTMLWriter object provides necessary support for high-performing Active Server Pages (ASP), which read XML documents with a SAX reader, put those documents through custom SAX filters, and output the data to the user as an HTML page. The MXHTMLWriter object is also useful for a number of other applications, like the manual generation of HTML pages.

  The XSLT processor can now accept the SAX content handler as output. This means that the chain of SAX filters can directly process the transformed XML. For example, you can use this feature to eliminate XML regeneration and reparsing, allowing XML documents to be consumed immediately by an application when incoming XML documents need to be translated to the same dictionary.

  The new MXNamespaceManager object allows you to manually track namespace declarations and resolve them, either in the current context or in the context of a particular DOM node. Although MSXML supports namespaces, and can automatically resolve names of elements and attributes, there are more and more cases in which an attribute's value or an element's content uses qualified names. The new MXNamespaceManager object is readily able to track and resolve these qualified names.

• Removal of Legacy Code

  A number of legacy features have been dropped from this release. Most of these are features that are no longer necessary because of replace mode. The eliminated features include:

  • Old, non-conformant XSL, which is now replaced completely with W3 standard XSLT 1.0. Complete XSLT 1.0 has been available since MSXML 3.0.

  • Old, non-conformant XSLPattern language, which is now replaced completely with W3 standard XPath 1.0. Complete XPath 1.0 has been available since MSXML 3.0.

  • Old, non-conformant XDR rudimentary uuid: namespaces. Correct namespace for old XDR support are now the HTTP-based namespaces: urn:schemas-microsoft-com:xml-data and urn:schemas-microsoft-com:datatypes.

  • The old, non-standard NodeFactory interface, which was deprecated in MSXML 3.0. This interface was used for XML sequential parsing. It has been replaced completely with the SAX2 parser, which has been available since MSXML 3.0.

  • The normalize-line-break feature now has no effect with the SAX parser. Line breaks are always normalized per XML specifications.

• Separate WinHTTP Version 5.0 Component

  The functionality of the ServerHTTPRequest component is now provided by a separate WinHTTP component. This is a new server-side component that provides reliable HTTP stack functionality. Without the WinHTTP component, ServerHTTPRequest and DOM/SAX with server-side mode will not be able to access HTTP-based data. When you install MSXML 4.0 on a computer running Windows NT/2000/XP OS, you automatically install the WinHTTP component. However, this is not true for Windows 98/Me, on which WinHTTP does not work. You can still install MSXML on Windows 98 or Windows Me, but you will have to use the default DOM/SAX mode, or the XMLHTTPRequest object for HTTP functionality, which uses the WinInet component. The WinInet component is preinstalled on these versions of Windows with Internet Explorer.

  This release provides the slimmer, faster, and more conformant XML processing components, which can be used safely in a server-side environment of enterprise-grade systems. MSXML 4.0 can still be successfully used on the client side with a controlled environment when you can ensure installation of the component you want on the client computer, as in cases with non-thin clients.

• Substantial Improvements in XSLT Performance

  MSXML 4.0 provides a substantially faster XSLT engine than the one that was provided in MSXML 3.0. Internal testing by the MSXML team indicated that XSLT transformations performed using MSXML 4.0 were in the range of four to eight times faster than when those same transformations were performed using MSXML 3.0. MSXML 4.0 also provides a new DOM parser that provides stability and accelerated performance in contrast to the original MSXML parser, although you can decide which parser to use in your code. For more information, see NewParser Property.

• MSXML Name Change

  With MSXML 4.0, the full unabbreviated name of MSXML has changed. Originally, MSXML was a component to provide XML parsing, so the complete name was Microsoft XML Parser. Over the years, however, both XML and MSXML have grown. MSXML now provides far more functionality than just parsing. With MSXML 4.0, the new full name, Microsoft XML Core Services, reflects the new functionality that MSXML now provides for XML programming. Note that the abbreviated name is the still the same as before: MSXML.

The Microsoft XML Parser (MSXML) 3.0 release provides several new features not available in previous production releases of MSXML.

• Support for Server-Safe HTTP

  MSXML 3.0 release provides a server-safe ServerXMLHTTP implementation, which provides functionality similar to the XMLHTTP object, except in a server-side safe way. To use server-side safe HTTP, use the IXMLDOMDocument2setProperty method or the SAXXMLReaderputFeature Method. Alternatively, you can use the new ServerXMLHTTP/IServerXMLHTTPRequest object on its own as a generic server-side HTTP access component.

• Compliancy with XSLT 1.0 and XPath 1.0 Specifications

  The MSXML 3.0 release supports every existing XSL Transformations (XSLT) and XML Path Language (XPath) feature included in the current standards. For answers to commonly asked questions about XSLT, see Frequently Asked Questions about XSLT. To get started with XSLT, see XSLT Reference.

• Support for Simple API for XML, Version 2 (SAX2)

  The MSXML 3.0 release provides event-based parsing with MSXML SAX2. Simple API for XML (SAX) is an interface that allows you to write applications to read data in an XML document. SAX2 is the latest version of this application programming interface (API). The MSXML SAX2 implementation, which provides both Microsoft Visual Basic and Microsoft Visual C++ interfaces, offers a simple, fast, low-overhead alternative to the Document Object Model (DOM) processing method.

  In the MSXML 3.0 release, there are no longer two separate SAX readers for C++ and Visual Basic, as was the case with previous technology preview releases. The same coclass, SAXXMLReader, now implements both sets of interfaces. This means that Visual Basic programs should create SAXXMLReader, not a VBSAXXMLReader class, as shown in the following.

  Dim reader As New SAXXMLReader

  Another important change from previous technology preview releases is that the parser passes strings to handlers by reference, not by name. This improves performance and avoids extra string copying. It also affects function headers in existing handler implementations. For example, an existing header might look like the following.

  Sub IVBSAXContentHandler_characters(ByVal strChars As String)

  You must change the header so that it looks like the following.

  Sub IVBSAXContentHandler_characters(strChars As String)

  The MSXML 3.0 release also includes helper implementations of the XML writer and SAX attributes. The IMXWriter Interface CoClass allows you to generate XML documents from a SAX events stream. The IMXAttributes Interface CoClass simplifies creation of an attribute object, if you need one for SAX-based XML processing.

  For more information about MSXML SAX2, see the SAX2 section.

• Namespace Support When Querying the DOM Using XPath

  MSXML 3.0 now supports an internal property (flag), SelectionNamespaces, so the IXMLDOMNode functions, selectNodes() and selectSingleNode(), can now use qualified names. For more information, see the setProperty Method of the IXMLDOMDocument2 object.