XML in the Browser: Architectural Implications

All the tools described previously in the browser anatomy section are available today, if not in forms that fulfill the standards committees’ specifications. Style sheets and dynamic documents are available in both Netscape and Microsoft browsers, although in different and incomplete implementations. Microsoft is using XML in its browser as well, although in a very limited way. Microsoft includes two scriptable parsers in Internet Explorer, but it still can’t display XML directly on the screen, or style it with CSS. The preliminary steps they have taken are promising but don’t nearly take advantage of XML’s potential.

We’ll start by looking at one of the first XML browsers, written by Peter Murray-Rust , a Java applet named Jumbo. Jumbo is the Java Universal Molecular (or Markup) Browser for Objects. Jumbo was written to handle Chemical Markup Language, an application of XML that uses markup to provide information on various molecules. Jumbo is written as a Java applet, making it a browser within a browser. Jumbo’s main screen is quite simple, using drop-down boxes for menus and providing a visual representation of the element tree for users to navigate, as shown in Figure 11.3.

Figure 11.3  A CML file containing information about a molecular spectrum.

Clicking on the graph icon next to the word Spectrum fires up another window, a Java applet that displays a mass spectrum chart, as shown in Figure 11.4.

Figure 11.4  Mass spectrum chart displayed by Jumbo.

Other information is available in the same file; a graph displaying mass information, created by another Java applet, is shown in Figure 11.5.

Figure 11.5  Mass chart displayed by Jumbo.

Although Jumbo was built to display chemical information, it is also quite capable of displaying other marked-up information. In Figure 11.6, Jumbo is displaying a small portion of the first scene of Julius Caesar.

Figure 11.6  Shakespeare in XML, displayed by Jumbo.

Although Jumbo’s interface isn’t comparable to its HTML competitors, it’s still an impressive achievement. Jumbo uses a relatively small set of core classes to process chemical information stored as markup and presents different views of those elements with small Java applets for graphs and other displays. The architecture is fairly simple: a parser, a tree display (the table of contents), and a set of Java applets that can present particular elements and sets of elements.

Jumbo’s architecture strongly suggests ways that XML could be used with current architectures to supplement the existing plug-in and object mechanisms for displaying content. Right now, all content that isn’t images or markup must be declared using special tags—EMBED, APPLET, or OBJECT. Adding plug-ins to a browser isn’t as smooth a process as it should be, and all these methods (with the possible exception of applets) expose users to the risk of damage from poorly written or malicious code. A more flexible architecture might allow users or documents to associate applets (or similar programs) with XML elements, providing element-specific processing either in the browser window or in separate pop-up windows. In this way, elements that just contain text can be displayed with the tools available for handling markup, while elements meant for further processing can receive it using tools they specify.

Implementing this architecture in the current browsers will undoubtedly create yet another arena in which the competing browser developers can built incompatible standards, APIs that refuse to interoperate, and code that works only with a particular browser. Still, XML itself includes a few features that could be useful for parts of this, like the NOTATION declaration. Even though using NOTATION to specify external viewers is rather obsolete in the age of the integrated browser, it may still have some use for XML as a mean of specifying external processing. A NOTATION declaration that links to a Java applet could be connected to an element with a #FIXED attribute, announcing to the browser that this element needs its own specified processing tool. In combination with other attributes specifying whether the element needs its own window or should be presented in-line, this could significantly ease the first steps of XML integration. The hard part will come in developing an API that allows the developers of those in-line presentation vehicles to negotiate size and location and to redraw with the browser.

Jumbo even goes so far as to allow users to pick their parsing engine! This kind of modularity promises enormous flexibility.