Enabling XML on All Browsers: Theory

When you point your Microsoft Internet Explorer (IE) 5.x browser to an XML document, the browser applies a stylesheet to the XML document's content and then provides the formatted content in its client area. If the XML document explicitly points to an Extensible Style Language (XSL) stylesheet, IE 5.x loads and applies the XSL stylesheet. Otherwise, the browser uses an internal, and somewhat generic, stylesheet to render the XML document. These events happen whether you point to the XML document through a URL and the HTTP protocol or navigate to the XML document through a file path and the FILE protocol. At the end of the day, you see a graphical representation of the content.

Suppose now that your favorite browser is any version of Netscape Communicator, Opera, HotJava, or any other non-IE 5.x browser (including IE versions earlier than 5.0). What happens then when you point your browser to an XML document?

Depending on the browser's features, when you point to the document through a URL, either you see the document rendered as raw text or the system asks you to indicate a local application to handle the XML file. What happens under the hood is that the browser tries to treat the XML data stream as if it were plain HTML text. When the browser doesn't recognize the tags because they don't match any predefined HTML tags, it ignores and excludes those tags from rendering and outputs only the raw data found between any pair of opening and closing tags. If you try to connect to an XML document through the local FILE protocol, the non-IE 5.x browser will probably ask you to run a program to handle the file. In either case, you don't get the results you want. Is there a way to enable all browsers to display XML documents?

The IE 5.x mechanism relies on browser-specific capabilities, and there's no way to export the mechanism to other browsers unless the other browsers are updated and recompiled. With Netscape's browsers, you could write a plug-in module and access the internal rendering engine, but this approach is problematic and requires advanced skills. The real answer lies in the Web server architecture and in the filtering and HTML-generation support it provides. Let's see what IIS offers.

In the IIS architecture, Internet Server API (ISAPI) modules play a key role. ISAPI is a sort of programming interface between the Web server and all server-side applications. By writing ISAPI modules, you can filter the data that goes back and forth between the client and the Web server, and you can change that data if you want. How does this apply to XML processing? A proper ISAPI module running on an IIS Web server can hook onto the XML data stream going back to the client after a request and transform it on-the-fly into raw HTML text. Such a filter gets into the XML data, applies an XSL stylesheet, and sends the results to the client. The browser in this case receives plain HTML text and renders it as usual.

To control which XSL stylesheet to apply, you could define your own algorithm that probably would be similar to the following one:

If the XML document points to an XSL file,    Then use it.Otherwise, use a standard one.

Architecturally speaking, you can easily replicate the ISAPI approach on any Web server; you simply take advantage of the appropriate server-side technology.

But how do you to write or get the proper ISAPI filter to enable ALL browsers to handle XML? For IIS-based systems, Microsoft offers a free tool, XSLISAPI, from the MSDN Online Downloads site. In the next issue, I'll cover this tool in detail.