A distributed system usually comprises several logical layers. One layer hosts workflow, one is for business logic, and one is for actual data access. Until a couple of years ago, very few developers were ready to use XML in any of these layers. They might have used XML in one of the back-end layers, but to transform XML data into something the browser could view, they resorted to HTML (a browser-based friendly version of their XML data). Then something happened.
As Internet Explorer (IE) 5.0 gained a wide acceptance, Web developers and designers realized that IE 5.0's XML direct browsing engine was worth more attention. As you probably know, XML direct browsing is the feature that makes IE 5.0+ capable of displaying XML code in a more pleasing way than as plain text. The direct browsing is tightly coupled with built-in support for XML stylesheets.
Together, XML and Extensible Style Language (XSL) make it possible to use XML in all the layers. XSL can transform XML either to another XML format or to plain HTML. The perfect application of this concept is dynamically choosing the HTML code according to the browser's capabilities.
The idea is that you use XML to describe the structure of the page, or smaller portions of the page, and then apply the browser-specific transformation rules hard-coded in XSL. At the design level, this approach is certainly simple. At a more practical level, it seems even simplistic. Let's see why.
When data is fetched from the data store, it's usually anything but XML. The data is transformed into XML some time on its way to the browser. In some fortunate cases (e.g., with SQL Server 2000), the result set is rendered as XML on the database box and hits your modules as XML code.
XML data traverses most of the layers in a distributed system. Then it stops close to the presentation layer. Here you have three possible alternatives. Which approach you choose depends mostly on the browser capabilities.
- You can fabricate the HTML page entirely on the server. Doing everything on the server is certainly the safest and simplest, but don't call it XML-driven pages—because it isn't. You're simply using XML to convey data to the Active Server Pages (ASP) layer across multiple back-end layers. Keep in mind that unless you're using a .NET Server and coding against .NET objects, and unless you need to exchange data with modules running on other platforms (i.e., non-Windows platforms or Windows platforms with different versions of the same libraries), there's no real performance hit in using XML in place of, say, ADO recordsets.
- You can bind the ASP-generated HTML page to server-side XML data and use a client-side script to finalize the page. XML data binding is an interesting technique that requires at least IE 4.0. A special module—either an ActiveX control or a Java applet—downloads the XML asynchronously on the client. But once you accumulate data locally, you need to refresh the page—which makes having Dynamic HTML (DHTML) critical. In addition, this kind of data binding (infinitely less powerful than .NET data binding) requires the XML data to follow a well-known, tabular, fixed schema.
- You can send XML code directly to the browser. With direct browsing, XML travels to the browser synchronously and is automatically processed on the client without requiring a script. Of course, the more you do on the client, the more you leave the server free to fulfill other incoming requests. Aside from this rather general rule, keep in mind the following things:
- If you send direct XML, XSL must be responsible for providing the rest of the UI (e.g., the button bar, images).
- Coding XSL isn't exactly a picnic and is anything but easily maintainable.
- You seriously risk replicating the same XSL code in all the different stylesheets you use.
Finally, if you plan to support mobile devices, such as Personal Digital Assistants (PDAs), be aware that using XML doesn't mean that the code for them is simply another stylesheet. For mobile application pages to be really effective and usable, you need to rethink entirely how your Web application presents information.