Out of the Angle Brackets
I’ve been working closely with the IE team leading up to the release of IE7 and looking at the use of XML in the browser. During this investigation one thing has become immediately obvious – there is a lot of confusion around the versioning story for MSXML and how to instantiate the “right” MSXML object in the browser. Here’s a quick snippet of code that I’ve seen all too often out on the web:
What NOT to do...
if (Web.Application.get_type() == Web.ApplicationType.InternetExplorer) {
var progIDs = [ 'Msxml2.DOMDocument.6.0', 'Msxml2.DOMDocument.5.0', 'Msxml2.DOMDocument.4.0', 'Msxml2.DOMDocument.3.0', 'Msxml2.DOMDocument' ]; // MSXML5.0, MSXML4.0 and Msxml2.DOMDocument all have issues - be careful when using. Details below.
for (var i = 0; i < progIDs.length; i++) {
try {
var xmlDOM = new ActiveXObject(progIDs[i]);
return xmlDOM;
}
catch (ex) {
return null;
The code iterates through the "progIDs" array and instantiates the highest version MSXML DOM that is available on the machine and returns it to the caller (see below for details on which versions ship where). This has at least a few implications:
My goal for this post is to give a quick history of MSXML lifecycle and versions, provide details with an example on implementing best practices with MSXML on the web, and talk about a couple key things to watch out for.
If you want the full story please read on, but if you’re short on time and want the quick scoop here it is in 4 bullets:
MSXML Lifecycle & History
OK, the full story requires a little bit more context – so let’s cover the different versions of MSXML, where they ship, and what the long term strategy is.
Over the long run, the goal is to have our customers move their applications to MSXML6. In terms of deployment, we want to ship our technology "in-the-box" with the operating system so that page authors and app developers can take advantage of it with zero deployment. However, our customers have told us they want symmetrical XML APIs on all supported OS platforms, so we still need a way to get the newest XML technologies to our downlevel OSes (Win2k, Win XP, and Win 2k3).
MSXML6 will be part of the Vista operating system when it releases, but requires a redistributable package to be installed downlevel. We’d like to get MSXML6 “inlined” in the next service pack of each of the downlevel OSes, but we need a strong business case to do so. So in the short and medium term we will continue to ship a redistributable package for MSXML6 that can be installed on downlevel operating systems. We'll try to get a post up on the benefits of moving to MSXML6 sometime soon.
As much as we'd love everyone to be on MSXML6 today, we realize the migration can take some time. So we're continuing to invest in MSXML3 to support existing applications and applications that have zero deployment requirements. MSXML3 doesn't have all the improvements in MSXML6, but developers should consider it a robust and stable platform for MSXML applications. MSXML3 is already part of the operating system on a fully patched Win2k SP4 installation and higher so in general no deployment to the client is required. Going forward, MSXML3 updates will come out in each of the OS service packs. MSXML3 SP7 is the last update to MSXML3 that should ship in redistributable form and in the future no redistributable package should be necessary for our partners and customers to use MSXML3 functionality.
MSXML4 was a predecessor to MSXML6 but hasn't ever shipped in the operating system. MSXML6 is a significant step forward in terms of reliability, security, W3C and System.Xml compatibility, and it also has support for native 64-bit environments. Right now we are investing much more heavily in MSXML6 and MSXML3 and we're encouraging our customers to move to 6 when possible and 3 when necessary.
Finally, anyone using MSXML5 who isn’t writing applications specifically targeted at Microsoft Office 2003 or Microsoft Office 2007 should migrate to MSXML6.
The details
Once you pick a version of MSXML to use, how do you do it effectively? MSXML ships side-by-side with version dependent ProgIDs. That means two things:
var xmlDOM = new ActiveXObject('Msxml2.DOMDocument.3.0') //uses MSXML 3.0 var xmlDOM = new ActiveXObject('Msxml2.DOMDocument.6.0') //uses MSXML 6.0
var xmlDOM = new ActiveXObject('Msxml2.DOMDocument.3.0') //uses MSXML 3.0
var xmlDOM = new ActiveXObject('Msxml2.DOMDocument.6.0') //uses MSXML 6.0
One related note - service packs of a particular version of MSXML are not side by side and will upgrade that version of MSXML to the service pack version. For example, if your computer is running MSXML3 SP5 and you install MSXML3 SP7, all applications that use MSXML3 will automatically be upgraded to run on 3 SP7.
Ideally, customers should standardize on MSXML6, but as mentioned above legacy applications or zero-deployment requirements may block full migration to MSXML6 in the short run. In this case there are two tensions that need to be balanced – functionality and test costs. This essentially leads to two options:
if (Web.Application.get_type() == Web.ApplicationType.InternetExplorer) { var progIDs = [ 'Msxml2.DOMDocument.6.0', 'Msxml2.DOMDocument.3.0']; for (var i = 0; i < progIDs.length; i++) { try { var xmlDOM = new ActiveXObject(progIDs[i]); return xmlDOM; } catch (ex) { } } return null; }
var progIDs = [ 'Msxml2.DOMDocument.6.0', 'Msxml2.DOMDocument.3.0'];
A couple things to watch out for
var xmlDOM = new ActiveXObject('Msxml2.DOMDocument.3.0') and var xmlDOM = new ActiveXObject('Msxml2.DOMDocument')
var xmlDOM = new ActiveXObject('Msxml2.DOMDocument.3.0')
and
var xmlDOM = new ActiveXObject('Msxml2.DOMDocument')
As always, I'd love to get some feedback from people so if you have questions, comments, or random thoughts you'd like to share please comment here or mail me directly (email link above).
Adam Wiener
Lead Program Manager
Data Programmability/XML Technologies
More or less in the random thoughts category, but have MSXML's problems with XHTML 1.1 ( http://www.satoshii.org/markup/dtd/xhtml11-msxml.en ) been entirely resolved (and, if so, in which version)?
Adam Wiener, Lead Program Manager for Data Programmability / XML Technologies, has worked closely with
Some of you may have noticed the following goldbar on some websites: Our friend Adam on the XML team
Hi Adam,
Thanks for the great post. Some of the mud is getting clearer! I have a very large AJAX application (well, suite of applications) that together comprise a corporate intranet (I'll omit the company). Currently that site is set to use MSXML4 SP2. If I change my <object> tags to install the MSXML6 CAB and if I change my ProgIDs to the 6.0 equivalents, what kind of compatibility problems am I likely to encounter? Is there a comparison document/table between the latest MSXML 6 and MSXML4 SP2 that I can refer to in order to assess the risk of such a transition?
Thanks!
Andrew Eberhard
Adam
Could you point out about XSLPattern versus XPath in version 3.0? I find this to be one of the commonest causes for code failing when working with different versions.
Joe
I run Windows 2000 Professional Sp4, and I much appreciate your clarification that MSXML 4 Sp2 is NOT the preferred fallback MSXML version below MSXML 6.0.
So I will upgrade my three Win2k computers to MSXML 6.0 (without the SDK since I am not a software developer in any way), provided that MSXML 6.0 works not only with MSIE 7 (which I believe will not be available for Win2k) but also with MSIE 6 Sp1 in Win2k.
I urge you to explicitly include somewhere that MSXML 6.0 DOES (or does not) work with MSIE 6 Sp1.
Thanks.
Roger Folsom
rnfolsom@netscape.net
Thanks for this post, it explains some of the issues we had with our xml editor (Xopus) in IE7.
However, your statement to use either MSXML3 or MSXML6 contradicts my experiences. In Xopus we need XMLHTTPRequest, XSLT 1.0 support and SchemaCache.
AFAIK doesn't MSXML3 fully support XSLT 1.0 and has no SchemaCache object so we can't use it.
MSXML4 and 5 work well for us, Office 2003 is widely spread, especially amongst our user base. We haven't had issues with MSXML5 due to it's specialization towards Office.
MSXML6 has breaking changes in SchemaCache (Support for Partial Schemas and Schema flattening) that requires us to rearchitecture our validation infrastructure. We haven't found the resources to do this yet.
So we ended up supporting only MSXML4 and 5, the exact opposite of what you're suggesting. Now with IE7 we seem to be forced to drop MSXML5 support as well.
Why shouldn't we support MSXML4, MSXML5 only in IE6 and MSXML6 as soon as possible?
Huge thanks for clarification... Good and very helpful article.
Benjamin, XHTML support is something we're looking at right now in both MSXML and System.Xml. Thanks for the great pointer to the analysis on the Satoshii site - I love getting the feedback on what people are experiencing with our products in the real world. The IGNORE issue is still there and we don't support HTML entities without a declaration in the DTD (  is the most famous). In terms of resolving externals we will resolve relative to the resource URL in MSXML6 - it simplifies our security model particularly in the browser and ensures malicious documents can't harm browsers when they are surfing.
Best Regards,
Data Programmability / XML Technologies
To Joe and Laurens - thanks for your insight. I'll edit the main post to take your feedback into account. Thanks for sharing and helping to broaden our best practices guidance for everyone.
What's the recommendation for distribting a solution that calls XMLHTTPRequest (ie, I do not control the users environment and am looking for the broadest current support)?
ie. what's the best Curl-equivalent for Classic ASP?
To Roger, MSXML6 will work with any supported version of IE6 as well as IE7. If you do take the time to install it, any pages that use the "fallback" method above will be able to take advantage of your shiny new installation of MSXML6.
Hi Andrew, right now we don't support CAB installation for MSXML6. But we've heard from a bunch of folks now that this is an important scenario so we're looking at wrapping our existing installer. In terms of migration between 4.0 and 6.0 you can look at the "Things to watch out for" section above and also look at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/xmlsdk/html/cb34f1f0-c235-4d6c-8fc0-1c337dadb56f.asp to see what's new in MSXML 6.0