Most CIOs have been around long enough to remember the sense of wonder in using a graphical interface for the first time. Even though the interface was slow and confined to accessing only local applications and resources, it was a quantum leap beyond a command line. Then the Web expanded our vision of what resources we should be able to reach with the click of a mouse. But with the advent of cell phones and wireless networking, it’s somehow no longer good enough to be able to access the Web only from your desktop.

Our customers and employees are beginning to expect that they will be able to access our Web services from common mobile devices like pagers and cell phones. Personal Digital Assistants like the Palm VII now allow you to stay connected to the Web wherever you go. As the number of these Web devices grows, we need to be able to design our Web applications and services in such a way that people can use these devices to access our sites, or we’ll be left at a competitive disadvantage. Redesigning your systems to use a mix of structured and unstructured stores will enable you to meet the demand for supporting these next generation Web devices. The combination of XML and XSL technologies will allow you to meet this important business objective. Here’s how it works:
In this series on XML, we’ll look at how XML will change the very nature of the Web from a collection of online brochures mixed with a few transaction systems into a dynamic resource that allows systems and devices to interact. In part one , we looked at the brief history and intent of markup languages, and how XML will change the way we store and utilize Web resources. In part three, we’ll examine how these changes affect businesses, and later, in part four, we’ll look at how it will affect users.
Using Web devices with style
To see how XML and its companion technology XSL (the eXtensible Stylesheet Language) will help us address these problems, we first need a little Web development history refresher. When Web developers first began posting pages, they had to develop them to conform to a specific version of HTML. For example, HTML 2.0 browsers would not support frames. Therefore it became necessary to not only detect the version of HTML that the browser would support, but also provide either pages that conformed to the least common denominator or to create sets of pages for each version of HTML that was to be supported. This problem has been compounded by the fact that we’ve not only had to deal with multiple versions of HTML (2.0, 3.2, 4.0) but with client scripting languages (JavaScript, Jscript and VBScript) and different manufacturers’ support of HTML standards (Mosaic, Microsoft, Netscape).

Now, to make matters interesting, multiply these combinations by the number of potential new devices that could use Web protocols in the future (watches, car radios, televisions, refrigerators, etc.). There’s just no way that the existing pool of available developers can create the sets of pages required to support all of these different device types. So how do we solve the problem? Enter XSL.

Think of XSL as a set of processing directives that tells a system how to render a particular XML data set. For example, suppose you have a site that stores your stock portfolio and you need to check its value from anywhere. Your portfolio could be represented by the following XML document:
<?XML version=”1.0”?>

When you’re at home or in the office where you have a powerful PC and an intelligent browser like Internet Explorer 5.0, you’ll want the information displayed in a rich, graphical format. This would include portfolio valuations, links to company Web sites automatically displayed, and the latest stock prices automatically downloaded. To accomplish this, the site would send the XML document down to your browser as well as an XSL style sheet that describes how the page should be rendered. Since IE5 supports XML and XSL, the browser will create and display the page using the processing power of the PC. Moreover, if you decide you want to see the data displayed in a different format, then you can download additional XSL style sheets without having to download the data again. The ability to process and render XML and XSL documents locally allows the Web developer to create rich, interactive user interfaces to be consumed by any system that understands these IETF standards. But what about your cellular phone, PDA or “Web watch?”

Well, it’s unlikely that any of these devices (at least in their first generation) will support XML and XSL natively. So how do you take advantage of the technology? Simple—allow the server to do the work! Web servers designed to support XML can make site development for these new devices much easier.

Suppose you want to display information from the same stock portfolio on your cell phone. First, create an XSL style sheet that can process the same XML file. But instead of producing the HTML that would normally be displayed by a desktop browser, it instead produces files conforming to WAP (Wireless Access Protocol, supported by most cell phone manufacturers). Now the cell phone can display the same portfolio information even though it has a much more limited display. Creating an XSL style sheet that supports PDA display standards, “Web watch” or “Web refrigerator,” allows the data to be displayed on these respective devices as well.

How XML changes Web development
If you ask your development staff how they currently handle the issues of supporting multiple browsers, they will tell you one of two things:

  1. “We don’t. We just support the least common denominator (HTML 3.2).”
  2. “We detect the browser type and then just point the user’s browser toward a totally separate set of HTML files.”

If they’re using the first method, then your site is not taking advantage of the rich formatting available to most Web browsers. If they’re using the second method, then you’re paying to maintain two virtually identical source trees with different sets of rendering commands. If you want to see them scream and run for cover, show them your Palm VII or your cell phone and ask to see a version of the Web site for one of those devices. Then tell them to sit down, take a deep breath, and consider redesigning future versions of the site using the XML/XSL method.

This method basically involves separating the site data into two piles of stuff. First, a single set of well-defined XML documents containing all of the data from the site. Second, separate all of the formatting directions into a set of XSL templates—one for each platform to be supported (HTML 3.2, DHTML, IE5, WAP, “Web Watch,” etc.). Next, write the browser detection and scripting code necessary to figure out what device is being used to access the site and then to either download the appropriate pairs of XML/XSL files (for IE5) or to direct the Web server to use XSL to transform the XML into the appropriate client format. Once they’ve gone through this exercise, future content can be placed in the first file and be rendered on any device. New devices can be supported by adding the appropriate XSL templates.

Will this get any easier?
As XML becomes a more standard method for passing data between applications and devices, more back end data repositories will begin consuming and emitting XML natively. For example, Microsoft’s next release of SQL Server (SQL Server 2000) will be able to return XML as the response to a query, which could be passed on to the appropriate XSL template and rendered to the appropriate device automatically. The upcoming Exchange 2000 release supports a new data store (called a “Web store”), in which all individual elements (mail messages, contact records, appointments) are stored as XML documents and can be displayed in the new Exchange Web client using standard XSL templates. This native support for XML and XSL will make it even easier to develop future Web applications that support multiple client devices.

Tim Landgrave is the founder and CEO of eAdvantage. eAdvantage assists small to medium-sized enterprises in the development of their electronic business strategy.

Tell us about your experiences with XML by posting a comment below. If you have a story idea you’d like to share, please drop us a note .