Recently in this column, I mentioned a somewhat surprising feature of Internet Explorer (IE) 5.0 and higher. Although these browsers understand XML and support Extensible Style Language Transformations (XSLT), they fail when it comes to validating XML content against a Document Type Definition (DTD) or an XML data schema. Probably for performance reasons, IE 5.0+ toggles off the validation flag that the Microsoft XML parser it is based on regularly makes available. If you're programmatically using this parser in your own code, you don't have a problem because the validation capability is turned on by default. However, no easy way exists to force IE to validate any XML content it's going to display.

When you try to view the source code of an XML page subject to XSLT, you discover another drawback of IE. You can't view the final HTML code. The browser displays only the original XML source code.

Recently, Microsoft made a tool available that, once properly installed on a client machine, causes IE to display two new options—Validate XML and View XSL Output—in the context menu you get when you right-click any displayed page. Although these two menu options are enabled for all possible documents you see through IE, they work properly only for XML documents. The former lets you validate the document on the fly. The latter causes a second browser window to pop up with the HTML source code that the browser is processing.

The Validate XML option runs a JavaScript code snippet similar to the following:

var win = external.menuArguments;
var doc = win.document;
var xmldoc = doc.XMLDocument;
var vdoc = xmldoc.cloneNode(false);
vdoc.async = false;
vdoc.validateOnParse=true;
vdoc.resolveExternals=true;
vdoc.load(xmldoc);

The code gets a reference to the XML Document Object Model (XMLDOM) object and clones it. Cloning the XMLDOM isn't strictly necessary but is more efficient than instantiating a brand new object through COM. The code initializes this second XML document with the content of the XML document being displayed. The difference, however, is that before the method load is called, the validateOnParse property is explicitly set to true and the parser's validation engine is enabled to work.

As I mentioned earlier, IE is capable of applying XSLT, but—by design—it doesn't show the final HTML source code through the View, Source menu item. To make up for this, the new View XSL Output option runs another handy snippet of JavaScript code:

var srcwin = win.open("about:blank", "",
      "resizable=yes,scrollbars=yes");
srcwin.document.write(
    "<html><title>XSL Transformation Ouput</title>" +
    "<body style=\"font:x-small 'Verdana';\"> +
    "<nobr id=x>Working...</nobr>" +
    "</body></html>\n"
);
x = srcwin.document.body.all("x");
x.innerText = xmldoc.transformNode(xsldoc);

This code opens a new browser window and fills it with dynamically generated HTML code. This HTML page contains an element with an ID of x whose innerText property is filled with the output of transformNode applied to the current XSL and XML documents.

The Internet Explorer Tools for Validating XML and Viewing XSLT Output are downloadable from the XML Development Center. After you have the self-extracting executable (iexmltls.exe), unzip it in any folder. You'll have two pairs of HTML and INF files. Installing the INF files (simply right-click and select Install) enters the necessary registry changes to force IE to show these two new context menu options.