Microsoft Outlines XML Support in IE 5 Beta 2

October 14, 1998

Tim Bray

This week at their big Professional Developers' Conference, Microsoft will announce the features of the next beta of Internet Explorer 5.0. They will not, however, actually be releasing the beta; they haven't set a date for the release yet. The Conference, however, is a good opportunity for them to make their direction clear.

Last week, I got a walk-through of what's going to be in this beta. This article is concerned with the new news, i.e. things that we didn't discuss in our look over the last beta in June. I haven't actually had my hands on this beta, so the following reflects only what Microsoft says they're going to be delivering. They've been pretty accurate on this in the past, and since they were careful not to mention any dates, these claims are not very risky for them.

Direct XML Support

For readers of, the big news is that the next beta supports direct display of XML documents. This is a big step forward from the last beta, which could only display XML "islands" in HTML documents. This means that you can send IE5 a document with a MIME-type of text/xml or application/xml, associate a stylesheet with it, and it will display directly. The stylesheet can be either CSS or XSL (more on XSL below).

There is a bit of a soft spot as to how the XML support will work with the DOM. We assume that internally IE transforms the XML to HTML before displaying it (which is how the Mozilla betas have been doing it). The soft spot is whether a DOM programmer accessing an XML page actually sees the pre-transformation XML elements and attributes, or only the HTML version that actually gets output.

This is a pretty serious soft spot. Since XML + CSS does not really have any serious display advantages compared to HTML + CSS, the main reason why you'd want to send XML to a browser is to run some code on it after it gets there. The best way to do this is through the DOM, so a browser that supports XML but not the DOM is kind of unexciting.


When Microsoft gave me the briefing, the item they seemed most excited about was their XSL support. They've updated their XSL processor to conform to the latest W3C working draft of 18 August. They are not, however, treating XSL as a real stylesheet language, but as a transformation tool; the idea is, once again, that you transform your XML into HTML for display. We have grave doubts, just as we discussed above, as to the usefulness of this approach in the case where you're trying to use the browser as a programmable application platform.

On the other hand, there is no doubt that there are a lot of people who can make good use of a declarative transformation tool. So the transformational capabilities of XSL are important. Furthermore, given that users aren't flocking to new releases of browsers (the world is still running more version 3 than version 4 browsers), we're going to dealing with XML-oblivious browsers for a long time yet. One good way to do this is to use something like XSL on the server side to generate HTML for older browsers.

There is another risk factor in Microsoft shipping XSL at this time; there has been only one public working draft, the XSL spec is not scheduled for completion until the middle of next year, and anyone who really puts XSL to work needs to know that the final standardized version is almost certainly going to change significantly from the current draft. We hope the Microsoft product evangelists make this risk crystal-clear to IE's users (developers in particular) so that we don't get a population of legacy documents that are locked into an obsolete, unstable version of the XSL spec.

Don't Forget CSS

There is, of course, another stylesheet language available, and one that doesn't suffer from the risk factors and instability of XSL. That would be CSS 1, which has been stable since December 1996, or maybe even CSS 2, stable since last May. It seems obvious to me that for anyone who wants to deploy XML in production mode right now, XML + CSS is the way to go, so I pressed Microsoft on this issue. The answer was pretty good: the level of CSS support for XML will be identical to that for HTML. I really wanted to hear a commitment that this would include full support for the 21-month old CSS 1 spec, but Microsoft couldn't make that promise. They do, however, plan to support a very large part of CSS 2, which is all to the good, but it would certainly be nice to have them finish the job on CSS 1 first.

Other MSXML Goodies

There are a few other goodies, mostly manifested as programmer-visible methods on the msxml object library. First of all, these methods include direct access to node transformations via the updated XSL machinery.

Secondly, there will be support for schema-driven validation. The schemas in question are advertised as a "subset of XML-Data that corresponds to the DCD features", and are accompanied with a caution that this is a technology preview, and that Microsoft parsers will be updated to the conform to whatever the W3C eventually blesses as a schema syntax.

Also, MS has extended the query-like pattern-matching facility of XSL to make it entirely recursive, support deep nesting, and fact make it usable as a general query language. There is no guarantee that the XSL committee or any other organization will follow this route, but this should be interesting if only as a proof-of-concept experiment.

There will be support for VML, Microsoft's new vector graphics language; I questioned the advisability of this, since VML has received nobody's blessing and in fact the W3C plans to combine several proposals into a "Single Vector Graphics" (SVG) facility. Microsoft's position is that VML is going to be the Office 2000 vector graphics format (nobody disputes that Office needs such a thing) and thus the browser needs to support it so that it can display Office documents.

To Summarize

Microsoft's XSL efforts are very impressive, but (readers will pardon us being something of a broken record on this subject) XSL is in the future. We are convinced that from the point of view of the largest number of users, the most important things that Microsoft could do in IE 5 would be:

  1. Ensure interoperability of XML and stylesheets with other browsers, and
  2. Build in conformance to existing, stable, well-understood standards such as CSS 1.0.

Innovation, of course, is fine and necessary, and we salute Microsoft's leadership in this area. But innovation needs to be built on a foundation of interoperability and playing by existing well-understood rules.