Lightweight client support for XML has largely been ignored in the XML revolution. This may be a reflection of the role of the client-side developer. Traditional client-side developers have all but disappeared from many contemporary web application developments, ever since n-tier architecture has displaced the client-server paradigm in the enterprise.

Therefore, if the developers themselves have slimmed down in numbers, the tools they use are bound to become less common. The lack of these tools is also perhaps a construct of what today seems a predominantly server-dominated industry. Perhaps they are lacking because of the ease with which web applications enable developers to forget about them.

Prevailing attitudes can be summed up this way: "Anyone who understands my DTD or XML Schema, can display this document class as they please." Even server-side developers churning out WML today are probably still treating WML as yet another document class that their server application needs to support.

But the number of document classes being published by enterprises grows every day. Servers that produce one or more of these myriad of XML formats (WML being one of them) suddenly complicate things on the lightweight client where slick heavyweight browsers with ActiveX controls don't exist. Lightweight clients simply don't have the capabilities and resources available to browser environments.

The role of the lightweight client-side developer has now been boosted to that of browser developer or "XML processor" developer. More generally, the client-side developer now has a rejuvenated role as a Java XML developer in the world of lightweights, especially with the success of the Java 2 Platform, Micro Edition (see J2ME, page 571). In the future, if the modular and lightweight XHTML Basic (see Too Many Client Formats, page 567) becomes popular and natively supported by vendors, client-side development may be relegated back to that of scripting with most work done on the server-side. However, we have not yet reached that point.

Most contemporary discussions about XML technologies focus around server-side issues, such as document generation from a relational database, document parsing and persistence to a data store, document transmission, or document transformation for an anticipated client (such as a Compact HTML browser). When client-side issues are addressed, they are often limited to Microsoft Internet Explorer or Netscape Communicator.

Case in point: Microsoft has substantive support for XML with MSXML in Internet Explorer. The latest release of MSXML, 3.0, supports:

• XSL Transformations (XSLT)
• XML Path Language (XPath)
• XML Namespaces 1.0
• DOM
• SAX 2.0
• Organization for the Advancement of Structural Information Standards (OASIS) XML 1.0 test suite
• Secure server-to-server XML with HTTPS

So, what do we do if we need to parse, generate, or transform XML on a lightweight client? Do we even need to do this at all?

The Need for XML On Lightweights

The future will show that, as Java and XML developers, we must pay more attention to XML technologies on lightweight clients. Even server-side-only developers, who today often just transform their XML into a subset of (X)HTML supported by the most common browser, will have to change their approach.

There are at least five reasons why you need or will need to parse, process, generate, and transform XML on lightweight clients. We will go into detail on each one of these:

• Lightweight client-side development. If you're a lightweight client-side developer that will be receiving content from providers who publish XML, you will need a way to parse and process XML documents of their document class. You may also need to generate XML documents to send back to the provider

• Too many client formats. If you're a lightweight client-side developer and your client is going to receive content from multiple providers, each of whom publish XML using different schemas (very likely given today's state of affairs!), you may want to transform those documents into a generic document class before processing them. As a server-side developer, you may want to publish your content in one form, instead of trying to keep up with all the latest standards and recommendations, and push the burden of transformation to the client

• Peer-to-Peer networking. If your lightweight client application is part of a peer-to-peer network or you are designing a peer-to-peer network, you may want to communicate with the other clients in the network through XML

• Information appliance interoperability. Embedded devices, smart consumer electronics, PDAs, mobile phones, and Internet appliances can all interoperate with each other and the Internet using technologies such as Bluetooth, Jini, Ricochet, CDPD, GSM and GPRS, WiFi (802.11b), and HomeRF. The need for common data exchange formats grows as the interoperability of these devices grows. Even if the underlying communications mechanisms are black boxes, the application developer is presented with new opportunities and challenges, as he now has a multitude of information appliances connected that previously weren't

• Powerful lightweights.If you extrapolate Moore's Law, we'll all eventually have turbo-charged mobile phones and PDAs at a cost too cheap to ignore. We could use some of that power for XML-related and XSLT tasks