The latest version of Microsoft XML Core Services (MSXML
4.0) complies with the World Wide Web Consortium (W3C) 2001 XML Schema
Numerous features in this version provide XML Schema support. You can
validate XML against XML schemas in both SAX and DOM using either an
external schema cache or xsi:schemaLocation/xsi:noNamespaceSchemaLocation
attributes. Although there is no XPath 2.0 yet, MSXML 4.0 provides extension
functions, permitted by standards, to support handling XSD types in
XPath and XSLT.
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 (XSD) recommendation, MSXML continues to support XML-Data
Reduced (XDR) and document type definition (DTD) validations.
MSXML 4.0 provides the new, faster XML parser and a substantially improved
XSLT engine. You can use the new parser with DOM by setting the NewParser
property to True, e.g. xmlDoc.setProperty("NewParser",
The new parser does not yet support asynchronous DOM load or DTD validation.
However, everything else functions the same way as with the old parser,
only faster. Microsoft's tests of MSXML 4.0 showed about 2x better
performance for pure parsing, and more than 4x better performance for
XSLT transformation. Other test claims I've seen show up to an 8x
better performance. My own tests confirm this, but I would be hesitant
to make such claims, although my tests -- mostly because of time constraints
-- have been less than "Lab Quality".
Extended Support For Sequential XML Processing
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
* Tracking of namespace declarations
You can now use the MXXMLWriter object to generate SAX events from a
DOM tree. You can also build a DOM tree out of SAX events. This feature
allows you to closely integrate DOM and SAX in your applications. For
developers who really want to integrate complex XML processing, this
opens up a whole new world of efficiencies.
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 support for high-performing Active Server Pages, which
can now 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 such as the manual generation of HTML pages. You
will also find corresponding classes in the .NET platform to do things
like this, with fine - grained control over the output.
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. 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 programatically
track namespace declarations and resolve them, either in the current
context or in the context of a particular DOM node. Of course MSXML
supports namespaces and can automatically resolve names of elements
and attributes, but there are many cases in which an attribute's value
or an element's content uses qualified names. The MXNamespaceManager
object tracks and resolves these qualified names.
Separate WinHTTP Version 5.0 Component
The former functions of the ServerHTTPRequest
component are now provided by the separate WinHTTP component. This is
a new server-side component (which has been in separate BETA as a stand-alone
component for some months, with its own newsgroup on MS) and which provides
reliable HTTP stack functionality. Without the WinHTTP component, ServerHTTPRequest
and DOM/SAX with server-side mode can not access HTTP-based data. When
you install MSXML 4.0 on a computer running NT / 2000 / XP, you automatically
get the WinHTTP component. Windows 98 / Me / 95 can not
support WinHTTP. You can still install MSXML 4.0 on Windows 98 or Windows
Me, but you will have to use the default DOM/SAX mode, or the XMLHTTPRequest
object, which uses WinInet.
The RTM release provides more compact, faster, and more conformant XML
processing components to be used in a server-side environment with enterprise-grade
systems. MSXML 4.0 can still be used on the client side in a controlled
environment where you can ensure installation of the component on client
machines, as in cases with Intranet or trusted site environments and
applications. Now let's look at a few of the negatives (at least for
some of us).
NewParser Property to use new Parser
The NewParser internal property
(flag)- True/False holds a value indicating whether MSXML uses the old
or new internal parser when loading DOMDocument objects.
IMPORTANT: If you
want to use the new faster parser, you must explicitly set this flag
This property is transitional for the period while MSXML provides
a choice of two internal parsers. The new parser is faster and more
reliable, but it does not yet support asynchronous mode or DTD validation.
Once the new parser has been updated to provide for asynchronous mode
and DTD validation, this property will always be set to True.
If the newParser property is set to False, which is the current default
setting, subsequent DOMDocument objects are loaded using the old parser.
If this property is set to True, subsequent DOMDocument objects are
loaded using the new parser.
For example, the following code makes a DOMDocument object use the new
parser when loading.
xmldoc.setProperty("NewParser", True );
Side-by-Side Functionality and the Removal of Replace Mode:
Until MSXML 3.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. Now replace mode is completely removed
from MSXML 4.0 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. MSXML 4.0 can still be used
in the traditional way to manipulate XML within an HTML page using a
Removal of Version-Independent ProgIDs
Version-independent ProgIDs are gone. This provides true side-by-side
installation, compared to previous versions in which some ProgIDs were
upgraded with the installation of a new version of MSXML. Now CreateObject("MSXML2.DOMDocument"*)
will not instantiate the MSXML 4.0 DOM, but a previous version (if it
is registered). If you want to use MSXML 4.0, you must use a ProgId
like this: CreateObject(*MSXML2.DOMDocument.4.0*). With C++ and Visual
Basic you will create "MSXML2.DOMDocument40". Similar changes
will be necessary with all other MSXML objects in order to use the MSXML
The reason for this change is to improve the maintainability of code
which otherwise would be error-prone when unexpected changes occur in
the environment. Version-independent ProgIDs were great for developers
trying MSXML, but proved risky in a production environment. If a user
developed code with version-independent ProgIDs, expecting MSXML 3.0
to be in place, and later installed or reinstalled SQL Server, for example,
they might find that they were using MSXML 2.6 instead of MSXML 3.0.
Removing version-independent ProgIDs in MSXML 4.0 kind of "bites
the bullet", eliminating such instability, and improves MSXML as
a server-side enterprise-grade component.
The release version of MSXML 4.0 is shipped with the same DLL names
(msxml4.dll, msxml4r.dll, and msxml4a.dll) as in preview releases. With
version-independent ProgIDs removed, this guarantees that MSXML 4.0
will not interfere with any versions of MSXML (2.0, 2.6, or 3.0) previously
installed. If you have code that uses version - independent ProgID's
instantiating MSXML 3.0 or 3.0 SP1, the installation of MSXML 4.0 RTM
should have no effect whatsoever. Windows XP Side-by-Side installation
does this in an even more integrated manner. This means that with Windows
XP, you can use the special side-by-side functionality to manage how
your applications are using MSXML and which versions (starting from
MSXML 4.0) that they are using. You'll create a Windows XP application
manifest which will link your application to the specific version
of MSXML 4.0.
If you have MSXML 4.0 Previews installed (April or July Technical
Preview Release of MSXML 4.0):
Direct upgrade from previews to RTM is still supported. You will have
to uninstall preview, and after that install RTM. You might have to
manually unregister and remove msxml4*.dll files from your system32
directory. To unregister the MSXML 4.0 preview, run:
regsvr32 /u msxml4.dll
If you have the MSXML 4.0 April Technical Preview Release of MSXML 4.0
Note that version-independent ProgIDs have been removed from MSXML 4.0
(despite having existed in the April release), so installing this release
will make them non-functional. This might seriously affect a number
of applications (such as Microsoft Visual Studio® .NET setup)
that use MSXML 3.0. To avoid this problem, run the following two commands
from the command line and delete msxml4*.dll files from the system32
directory before installing this release.
regsvr32 /u msxml4.dll
Note that after unregistration you might have to manually delete
msxml4*.dll files from your system32 directory.
Some Final Comments:
MSXML 4.0 RTM represents what I believe
is the final stage in the evolution of Microsoft's COM - compliant XML
technologies, ex "Dot Net". Developers and organizations who
want to be able to upgrade their code base will be well-advised to use
global constants application - wide for the instantiation of Version
Specific ProgID's. In. this manner an entire application's source code
base can be upgraded by simply doing a search and replace of ,for example
"strMSXMLVersionNum='.3.0' and changing the 3 to a "4".
In addition, it is possible to use the temporary "NewParser"
property in code in an "if" test such that: if(strMSXMLVersionNum=".4.0")
However, conversion may not be that
smooth. Developers should be ready to run in to additional problems
most of which will revolve around that fact that older, non standards
- compliant code in XPATH - type statements, replacement - type variables
such as "$any$" and other previously acceptable constructs
will no longer work under MSXML 4.0 RTM. It's time to meet the W3C and
bring the company's code base up to standards if you wanna play, and
unfortunately it may not be a picnic.