Client-side XML
IBM 
XML | XML on the Desktop: A Case Study of the Document as Application at Shell | Table of contents | Indexes | Accessing LDAP Data with XML | |||
| Browser-independent rendering Client-side XML IBM XML | IBM's XML Enabler: Making the World Safe for XML |
| IBM Corporation North Carolina Research Triangle Park Tidwell, Doug | Doug
Tidwell
Advisory Programmer , IBM Corporation
Biographical notice Doug Tidwell is an Advisory Programmer at IBM. He has well over a tenth of a century of programming and technical writing experience, and has been working with XML-like applications for several years. He holds, with special gloves, a Masters Degree in Computer Science from Vanderbilt University and a Bachelors Degree in English from the University of Georgia. His specialty is developing markup-based tools that create user interfaces and simplify data interchange. |
Introduction |
| Although there is widespread agreement on the potential of XML, little progress has been made towards making XML-tagged data accessible in a platform-independent way. In this paper, we discuss several strategies and technologies designed to let any user get as much out of XML-tagged data as their particular platform allows. |
Strategies for Rendering XML |
| One of the perceived impediments to widespread XML use is the relative lack of XML support in the average browser platform. While it is true that many browsers lack the ability to do anything useful with XML, the ability to describe structured data with XML brings tremendous power to web applications. Our goal is to allow anyone on any platform to view XML-based data using any browser. |
| Our first strategy is to use the capabilities of XML-enabled browsers. Next, we attempt to use Dynamic HTML (DHTML) in browsers that support it. While this is not as robust as a pure XML solution, it does allow us to support multiple views of the same data. Finally, for browsers with no support for XML or DHTML, we use the Java servlet architecture to convert XML data into ordinary HTML. |
| Having addressed the browser limitations on the client, we turn our attention to the server. We discuss ways to generate XML data from back-end data stores, including an LDAP database and a legacy 3270 application. Finally, we look at ways to make the XML transformation process as invisible as possible for the end user. |
| The ultimate goal of all of this work is to begin using XML to its full potential today. |
Taking Advantage of XML-Enabled Browsers |
| The obvious first step in bringing XML-tagged data to users is through the first wave of XML-enabled browsers (all one of them, Microsoft's Internet Explorer 4.0). |
| Our sample application serves up sample results from a figure skating competition. Using the ActiveX XSL control from Microsoft, several different views of the data are generated: |
One View of XML-Tagged Data in Internet Explorer 
|
Another View of XML-Tagged Data in Internet Explorer 
|
| The data generated uses tags such as <competitor>, <event>, and <judge>. The XSL control uses an XSL stylesheet to generate an HTML version of the data. Users can click on links that cause the XSL control to generate a new view of the data by using a different stylesheet. |
| The main advantage of this approach is that it greatly reduces the load on the server and the network. The server merely serves up the data as XML; the client has the responsibility of getting the correct stylesheets, running them against the data, then generating and rendering the views. Network access to generate new views is necessary only if the stylesheet must be retrieved from another host. |
The Dynamics of Dynamic HTML |
| Although Netscape Navigator Version 4.0 does not have native support for XML, we can still use the power of Dynamic HTML (DHTML) to display multiple views of a data set to the user. |
| Our strategy here is to generate several different views of the XML data, then build a single document that includes all of them. Only one view is visible at a time; as users click links on the page, different views are displayed while others are hidden. |
One View of XML-Tagged Data in Netscape Navigator 
|
Another View of XML-Tagged Data in Netscape Navigator 
|
| The advantage of this method is that all of the views are defined when they reach the client. Because the client does not have to build or rebuild each view, the client can switch between different views with much better performance. |
| The disadvantages of this approach is that the server has to do more work, and that the amount of data moving across the network may be several times greater. Despite these disadvantages, this is still preferable to having the server regenerate each view in response to each request by the client. |
I Don't Know What Your Browser Is, But It Tastes Like Chicken |
| Despite the efforts of the best marketeers on the planet, some users still persist in using browsers other than Netscape 4 and Internet Explorer 4. Even more incredibly, some users are so perverse as to use platforms other than Windows. While the developers at Microsoft and Netscape are to be commended for their efforts in adding XML and Dynamic HTML support to their browsers, the facts of the marketplace dictate that we support more feature-challenged browsers. |
| Our approach here is to use XML and XSL to generate a single view of the data. This view contains links to other views; those other views are simple hyperlinks to other documents. In this model, the client browser is a dumb terminal that merely displays whatever data the server delivers. |
| The following figure displays a view of our XML-tagged data in JavaSoft's HotJava browser. |
XML-Tagged Data in the HotJava Browser 
|
Yet Another View of XML-Tagged Data in the HotJava Browser 
|
| In the example above, when users click on a link to see a different view of the data, an HTTP request goes back to the server. The server then generates the requested document (or retrieves it from the cache) and sends it back to the browser. This process is repeated every time the user switches between views of the data. |
| Our final screen capture illustrates the same XML data rendered in Lynx, a browser with no graphics capabilities. For this browser, the data is merely displayed in tabular form without graphics or frames. |
A View of XML-Tagged Data in the Lynx Browser 
|
| Although the four browsers we used in our example have widely different levels of function, they can all generate similar views of the XML data. In each case, the data began as a series of XML tags; stylesheets were used at various points in the network to generate other views. The most important point here is that all of the browsers were able to display the data in the desired format. |
Mr. Webman, Check it and See / If There's a Stylesheet in Your Cache for Me |
| Although our stylesheets generate a wide range of markup, someone must establish the links between a given client type and an XSL stylesheet. There are a number of ways to approach this, but we have focused on two methods. |
| The first is to deliver a Java servlet that has the appropriate mappings hardcoded inside. While this is effective, it has no flexibility, and it can't be extended by a webmaster or webmistress. |
| The second method is to deliver a Java servlet that includes a TaskGuide (an XML-based wizard dialog, first demonstrated at XML '97) to configure the mappings between client types and XSL stylesheets. By default, the TaskGuide defines stylesheets for the most common browser types (Netscape 3.0 and 4.0, Internet Explorer 3.0 and 4.0, and a generic browser). The benefit to this approach is that it allows administrators to modify the default mappings and add new client types. |
| The XML Enabler component is built as a Java servlet. The servlet takes HTTP requests, gathers data from the XML data sources, then attempts to run the gathered data against an XSL stylesheet. The stylesheet is chosen based on client information delivered with the HTTP request. Finally, the output from the stylesheet engine is delivered via HTTP to the requestor. |
| By structuring our component as a Java servlet, and by using the standard information in the HTTP header to determine the client type, we are able to use universally available protocols to automate the transformation of XML data. When combined with the flexible servlet configuration done through the TaskGuide, the XML Enabler becomes the heart of an XML-based document delivery system. |
Data, Data Everywhere, and Not a Drop to Drink |
| Having addressed the needs of most clients, we turned our attention to the back-end data sources that will drive the XML applications of the near future. We have worked on several projects that address this problem, including generating XML from queries against database systems and LDAP repositories. (More information about our work with XML and LDAP will be presented at a separate session of this conference.) |
| In this paper, we'll discuss work we've done to convert legacy data on host systems into XML. Our approach is designed to avoid changes to any host system or legacy applications. |
Screen-Scraping and XML |
| A common way to repurpose legacy data is through a "screen scraper" application. These applications begin with a description of a host data stream and instructions on how to run a host application. As the host application returns data in the data stream, the screen scraper extracts that data from various parts of the data stream. |
| The power of this technique is that it allows us to move the enormous quantities of data in legacy systems into the world of XML. There are many terabytes of structured data in the world; that data was gathered and organized at great cost. While the screen-scraping approach is more brittle than a true database link, it is a low-cost solution that generates quick results. |
Summary |
| Although there are many other ways to exploit XML, the few approaches we've outlined in this paper demonstrate its potential. XML can deliver useful, tailored data to any client, and XML can format legacy data so that its structure and semantics are not lost as it moves across the network. Practical, large-scale applications can be built on XML today. |
Acknowledgements |
| There are a number of IBMers whose work contributed greatly to this paper: |
| XML on the Desktop: A Case Study of the Document as Application at Shell | Table of contents | Indexes | Accessing LDAP Data with XML | |||