With the Java 2 Platform Micro Edition now a reality on PDAs, embedded devices, and actually shipping on some mobile phones, the possibility for rich Java applications with network connectivity on lightweight-clients is here.

All the lessons learned from the client/server days before XML are not forgotten simply because we're on a constrained device. If we want to leverage the benefits afforded by XML (which have been addressed by many other books and articles but is outside the scope of this chapter) on modern lightweight clients, we'll need a way to parse and process XML documents delivered to us by servers. From there, we can display the data to the user and/or store it locally.

We might then wait for user input, or gather system information, and package it up into an XML document for transfer to a server. For example, we might query the current price of an item on our auction web site.

Too Many Client Formats

Today there are numerous lightweight-client document classes. Here is a partial list:

• Compact HTML (cHTML) is used in the Japanese NTT-DoCoMo i-mode network

• Wireless Markup Language and WMLScript for WAP networks

• Web clipping applications for Palm.Net and OmniSky networks

• HTML, and even though most agree it is inappropriate for information appliances, most web sites are still publishing their content only in this format. There's even the HTML 4.0 Guidelines for Mobile Access, which describes what parts of HTML should be avoided for information appliances

• Handheld Device Markup Language (HDML), originally created by Unwired Planet (Phone.com /Openwave –) in 1995 and submitted to the W3C in 1997. It is not XML-compliant, nor does it have scripting capabilities as with WML's WMLScript (however, the Openwave WAP Edition browser does display WML/WMLScript as well as HDML, while its Universal Edition browser displays WML/WMLScript, xHTML, and cHTML)

• Proprietary formats, which may not even be XML, such as those for the Xircom Rex

• XHTML Basic, a W3C recommendation for a common (yet modular) information appliance document type. The recommendation can be found here.

However, the verdict is out on whether or not XHTML Basic will be widely adopted: it was only officially made a recommendation in December of 2000. Even if it does become widely adopted, the recommendation seems inherently "user-interface-centric". The introduction states, "Because there are many ways to subset HTML…" By "user-interface-centric" I mean that data-driven applications, such as some of those found in industrial control, probably care nothing about subsetting HTML. They may not benefit as much by using XHTML Basic as, for example, mobile phone applications. However, even if XHTML Basic takes off and solves the multiple document class problem for user-interface-driven applications, there will still be browser developers on lightweight clients who will need to parse, process, and generate XHTML Basic.

In the meantime, we can make a generic J2ME client that understands all of these formats, or as many of our custom formats as we like. By transforming each of these formats into our own document class before processing, we could reduce the size of lightweight client code significantly. You can use a tool like XSLTC (see XSLT Compiler, page 618) to do this. Then, you can parse and process the transformed XML with one of the parsers reviewed in this chapter or the parser that comes with XSLTC. You might also need to use XSL on the client-side if you are displaying to the user a single, integrated service which is actually comprised of multiple smaller services from different servers, each publishing content in a different document class.

But ultimately, why should the document provider care about what kind of client he talks? He should publish his XML with a DTD or schema, and leave the rest to the client. This follows the lessons of encapsulation and distributed object-oriented design that we've learned as a development community over the years, even if it goes against the popular notion of "thin clients".

Use XML Document Servers

Imagine trying to publish content and data in HTML, cHTML, WML and WMLScript, HDML, and in the Web Clipping Application format. No problem, you say: we store all our data natively as XML. All we have to do is write XSL transformations for each format and expose addresses where each content type can be reached.

That could be a lot of work to reach all the new devices or networks, especially as new document classes are popping up all the time and old ones are dying out so we'll have to keep on writing new XSL transforms. Here is a case in point: if WML/WMLScript overtakes the older HDML format in the US, it might spell doom for thousands of existing HDML applications. Fortunately, WAP gateways transform HDML into WML – but relying on infrastructure providers for upgrade paths is dangerous.

Instead of publishing content data in one of the formats we talked about above (such as WML), we should consider publishing it to the client in XML with an associated DTD or XML Schema. As discussed previously, the transformation process rightfully belongs to the client.

Peer-to-Peer Networks

Client-to-client networks, like Napster and Jabber (which have centralized directory services) or GnuTella (with no centralized directory service), have yet to explode in the information appliance world. Jini technology and Project JXTA are addressing them. Jini is a mechanism for connecting distributed services in a network using a directory service. Project JXTA is a mechanism for connecting distributed services in a peer-to-peer (P2P) network where no directory server exists. Additionally, data (called codat, to indicate anything from code, data, or applications, to text, images, serialized Java objects, or SOAP packets) is sent across JXTA pipes as XML.

JXTA is quite new, so there aren't many applications out there using it yet. However, it does come with a graphical application called InstantP2P. InstantP2P implements:

• Instant messaging within "peer groups"
• P2P file sharing

Peer groups are collections of peers that publish, limit, and control access to codat among other peers in the group. In addition, each peer group defines its own membership requirements to secure peer group membership.

The lack of widespread use of P2P networks might be partially due to the single-threaded operating systems that many information appliances employ. If you want to share applications or MP3s on your Palm OS device over a P2P network, for example, you won't be able to look up your wife's phone number at the same time.

Whatever the reason for the lack of their widespread use, P2P networks for lightweight clients have enormous potential. If we're to leverage the openness afforded by XML, we must give clients in P2P networks the ability to natively generate, parse, process, and transform XML. Then, the data (or codat) they exchange can be specified as XML documents.

Information Appliance Interoperability

What if you want your Java 2 Platform, Micro Edition mobile phone application to dial a phone number stored in your PDA?

If both devices are Bluetooth-enabled, and your mobile phone application uses the Java API for Bluetooth (JSR-000082, http://java.sun.com/aboutJava/communityprocess/jsr/jsr_082_bluetooth.html), we're almost able to dial that number. First, the address book application on your PDA must expose directory services in a standard way so that your mobile phone application can look up contact information. Then, the mobile phone application can request a telephone number, or an address book entry, and the address book application on the PDA can send a reply containing the telephone number.

The messaging format between the two applications needs to be understandable by both. It should also be generic enough so that other applications on the same or different devices could understand it.

If ever there was a cry for XML, this is one of them. The PDA application, as the document provider, needs to generate XML. The mobile phone application, as the document receiver, needs to parse and process XML. Only then can our applications take advantage of all the benefits of XML on a device-to-device level.

Powerful Lightweights

As of the time of writing, powerful lightweights are already available. For example, the Compaq iPaq 3670 comes with 64MB RAM and can be expanded to 128MB with an optional CompactFlash card. Instead of the extra RAM, we could choose an IBM Microdrive and we'll have 1GB of storage. With the Dual-Slot PC Card Expansion Pack, you can plug in two Type-II PCMCIA cards. Fill one of them with the Novatel Wireless Merlin for Richocet and you'd have 128 kbps wireless Internet access. In the other slot you could add yet another 16MB of RAM or perhaps a GPS receiver.

Consider all this, and that the unit has a built-in microphone, speaker, and even a light sensor, and I think you'll agree with me that this device can do more than some desktops.

Yet you don't see many people carrying these high-end configurations around, the most obvious reason for that being their high cost. A device like the one above, so outfitted, at present costs thousands of dollars.

If the past is any indicator, devices like this will come down in price and shrink in size. They may even become "wearable" (Sanyo has already announced a line of raincoats for sale in Japan that have a pocket custom-fit for your Palm). If all this happens we'll wonder how we ever survived without one.

So as prices come down and Internet appliances become more powerful and widespread, some of the burden of XML processing and transformation should be pushed onto the client. Complex XSL transforms and larger DOM trees won't pose problems, and the document provider can remain purely in its XML world. With powerful clients, client-side processing can become a reality.