Last month we focused on the need for compression when XML is transmitted over a wireless network (XML-J, Vol. 3, issue 3). We also looked at the use of XSLT to tailor a single XML document for display on multiple wireless devices, each of which might have different display capabilities.

This article continues the discussion of wireless XML with a look at wireless XML initiatives such as VoiceXML and WAP/WML. And we'll see how two of the hottest areas in computing - information security and Web services - apply to wireless XML.

Five years ago HTML's ease-of-use enabled the World Wide Web to grow at a dramatic pace. Anybody could create a Web page and publish it for the whole world to see. The goal of the VoiceXML initiative is to bring this same ease of use to the development of voice applications, which include interactive voice response (IVR) and automated speech recognition (ASR) systems. Up until now, developing for these systems meant learning an arcane programming or scripting language.

The VoiceXML 2.0 specification was issued by the World Wide Web Consortium as a working draft on October 23, 2001 (see www.w3.org/TR/2001/WD-voicexml20-20011023/. Real-world uses of VoiceXML include the delivery of road traffic information over telephones, and automated helpdesk systems. The developer doesn't need to worry about the underlying speech-synthesis and speech-recording technology. The VoiceXML engine takes care of that in the same way that a Web browser takes care of the rendering of HTML.

VoiceXML describes how to make audio "forms," which can be thought of as analogous to visual HTML-based forms. These audio forms play audio questions and record the user's voice responses. The interaction between the user and the VoiceXML-enabled application can proceed sequentially by following a predefined order of questions. However, VoiceXML provides a rich framework for flow control and scripting that enables "intelligent" applications to be developed. For an example, see Listing 1.

The "field" tag indicates that the user must speak an input value (in this case, a type of coffee) before control passes to the next element in the form.

The following is a sample interaction using this form:

C: (computer): Would you like a latte, mocha, or espresso?
H: (human): A beer, please.
C: I'm sorry; I did not understand what you said. [This is a platform-specific message used when the user's voice input doesn't match an entry in the coffee.grxml grammar.]
C: Would you like a latte, mocha, or espresso?
H: Latte.
C: [Control passes to the script "deliver-coffee.pl"]

As you can see, the items "latte," "mocha," and "espresso" are contained in a separate grammar file, with a ".grxml" file ending. This file contains words that the user is permitted to speak as a response to the question. An example of a grammar is shown below:

<grammar mode="voice">
<rule id="root" scope="public">
<one-of>
<item> latte </item>
<item> mocha </item>
<item> espresso </item>
</one-of>
</rule>
</grammar>

The grammar shown above has a mode of type "voice." This contrasts with grammars of type "dtmf" (DTMF stands for Dual-Tone Multi-Frequency). DTMF tones are the noises that phone buttons make when pressed. Somewhat interestingly, each DTMF tone is the sum of two tones played together (hence "dual-tone"). By using a DTMF grammar, our coffee-selection example application can be adapted to take key-presses in place of spoken input. An example of such a DTMF grammar, in which the user presses key 1, 2, or 3 on a phone to choose a coffee type, is shown in the next example:

<grammar mode="dtmf">
<rule id="root" scope="public">
<one-of>
<item> 1 </item>
<item> 2 </item>
<item> 3 </item>
</one-of>
</rule>
</grammar>

Wireless Markup Language was one of the first commercial applications of XML. WML was developed by the WAP Forum, a consortium of providers of wireless hardware and software products. WAP began with HDML (Handheld Device Markup Language) as its basis, and aimed to use the model of the World Wide Web and its protocols but in a more efficient language, more suited to the limited size, memory, and processing power of the wireless world.

The first Wireless Access Protocol specification drew flak because of a perception that the WAP Forum was needlessly re-creating technologies that were already present in the nonwireless world. Why bother using WML and WTLS (Wireless Transport Layer Security), the argument went, when XHTML and TLS are available already, and are proven in the field.

When the successful Japanese i-mode system bypassed WML and instead used cHTML, a subset of HTML, the writing seemed to be on the wall for WML. However, the next generation of WAP - WAP 2.0 - supports the W3C XHTML and CSS recommendations, as well as TLS, thus reducing the need for Web developers to learn new languages and technologies. Other new features in the 2.0 release include synchronization features - implemented using SyncML - to access calendaring and addressing information from remote devices.

With the release of WAP 2.0, WML continues to be relevant. So take a look at Listing 2, an example WML page, reusing our coffee choice example from before.

Reading this code listing from top to bottom, we can see that it begins with the familiar XML directive, which identifies the document as XML. The next line indicates that the document must conform to the WML DTD. After the <wml> tag, we see the first "card"; WML uses the analogy of "cards" to describe each single screen of text to be shown on a cell phone display, and a group of these cards is sometimes called a "deck." The <do> and <go> tags create a hyperlink in the form of a button, which a user can scroll to and choose, using the navigation bar on his or her phone. The "id" attributes of the card elements are used to target the hyperlinks, so that users who choose a mocha coffee, for example, are sent to the card called "MochaCard".

How this WML application is displayed depends on the cell phone or PDA that's used for viewing. For instance, in Nokia 6150, the "accept" attribute on a "do" element gives users an Options "button" so they can click Next.

Security is a hot topic at the moment, not just for wireless systems but for computing in general. In the area of XML, initiatives such as XML Signature and XML Encryption are vitally important. XML Signature provides for digital signatures that are XML-aware, enabling portions of an XML document to be signed, and enabling information about the digital signature itself to be expressed in XML format.

XML Encryption is at a much earlier stage of development than XML Signature, though its philosophy is somewhat similar. XML Encryption provides for XML-aware encryption, meaning that only a portion of an XML document may be encrypted and the information about the encryption is then expressed in XML format. XML Encryption and XML Signature bring the advantages of the XML world to the arcane and complicated world of information security, and also bring much-needed security capabilities to the XML world.

When XML is sent wirelessly, XML Signature and XML Encryption are just as important as when the medium is fixed-wire. Related initiatives such as SAML (Security Assertions Markup Language) and Microsoft's .NET MyServices (formerly code-named HailStorm) will also need to be addressed by wireless devices. Public key cryptography is typically used to generate digital signatures and to enable the exchange of encryption keys.

The problem for wireless devices is the lack of battery power, bandwidth, and processor speed necessary to implement public key cryptography. One solution to this problem is to use the relatively new Elliptical Curve Cryptography technology. ECC uses less processing power than other types of public key cryptography - for example, the famous RSA public and private key algorithms, which are based on prime numbers arithmetic.

Web services are a very hot topic right now, and provide a framework that promises to make XML ubiquitous as the means of connecting software services across networks. Web services make particular sense for wireless devices because they allow the device to act as a Requestor to Web services located on remote machines. In this scenario it isn't necessary for the wireless device to run the service itself; it just needs the ability to create an XML-based request, wrap it as a SOAP message, and invoke the remote Web service. To make the outgoing SOAP message, the wireless device may use a full-blown SOAP stack, complete with a Document Object Model. However, this may be out of the question for many small-footprint devices, due to the size of DOM implementations. The alternative is to use a pared-down DOM, using only the features needed for SOAP, or to simply not use a DOM at all, and to craft the outgoing XML using string-manipulation code.

Microsoft's .NET framework for Web services includes a technology called Smart Devices Extensions (SDE), which allows .NET applications to run on mobile devices. By .NET applications I mean applications that use Microsoft's Common Language Runtime (CLR), which provides many useful functions such as TCP/IP networking and string processing.

The most common example - for now at least - of a .NET-enabled mobile device is a Pocket PC. Examples of Pocket PC devices include the popular Compaq iPaq PDA. In order to create a Web service request from a Pocket PC, a SOAP implementation is needed (see for example the Pocket SOAP toolkit from Simon Fell at www.pocketsoap.com). In the Palm world the analogous way to enable a Palm device to consume Web services is to install a Java 2 Platform, Micro Edition (J2ME) virtual machine and a SOAP implementation (e.g., the SOAP package from Enhydra (kSOAP.enhydra.org).

In summary, we've rounded out our look at wireless XML by examining VoiceXML and WML, security, and how the hot new area of Web services applies to mobile devices. The defining theme of these two articles on wireless XML has been the limitations of the platform in terms of screen size, memory, bandwidth, and processing power. Although wireless devices will improve in performance, and wireless bandwidth will become more plentiful, the wireless world will always lag the fixed-wire world in terms of capability. Wireless XML technologies address this fact, and mean that the great benefits of XML are as relevant to the wireless world as to the wired world.

• Source Code