Wireless Markup Language

Feb. 28, 2000 12:00 AM

The ability to access Web content and send e-mail messages from a wireless phone has become a requirement for the rapidly growing segment of wireless Internet users. Application development for wireless devices can be more challenging than conventional Web development due to the inherent characteristics of wireless devices - small display areas, narrow bandwidth connections, limited means for user input and limited memory resources. In addition, there are disparate vendor-specific wireless devices and presentation mechanisms.

To address some of these issues, the Wireless Application Protocol (WAP) Forum has defined a standard for the presentation and delivery of information to, for example, wireless phones, pagers and personal digital assistants (PDAs). The Wireless Markup Language (WML) is a specification of the WAP Forum pertaining to the presentation of content and user interface behavior on wireless devices. WML was designed to accommodate presentation on limited-capacity devices such as wireless phones.

WML is an XML language that inherits the XML document character set and most of the XML syntax. The document character set for WML is the Universal Character Set that is currently identical to Unicode 2.0. WML is specified as an XML document type definition (DTD), and is supported on any device that is WAP compliant. This article focuses on using WML for delivering content for presentation on WAP-compliant wireless devices.

Before I discuss WML, I think an overview of the WAP development model will be helpful. WAP programming is based on the Web programming paradigm. The model, as shown in Figure 1, comprises three major components.

The client component of the model is a WAP user agent that can interpret WML and present WML content to a user in a form appropriate for that type of wireless device. As its name implies, a WAP gateway converts to and from the wire-based and wireless domain, translating requests and responses from the TCP/IP protocol stack to the WAP protocol stack and vice-versa. It translates Web content into compact, encoded formats to increase transmission efficiency over the wireless network. WML can be encoded using a scheme based on the WAP Binary XML Content Format. A WAP gateway is required to access WML content over the Internet using HTTP requests. The server component of the model consists of a Web server, servlets and/or CGI scripts that generate WML content in response to requests.

Now that you're familiar with how WML fits into the overall WAP environment, we can begin to discuss the WML syntax.

WML Essentials
WML content is sent to a WAP-compliant device in the form of a deck. WML decks can be stored in the form of static wml files on a Web server or can be dynamically generated by CGI scripts or servlets. A WML document or deck consists of one or more cards, each of which represents a unit of interaction with a user. Typically, a card presents information and allows a user to enter text or select from a list of menu choices. A user navigates from one card in a deck to the next.

In WML, an element describes markup information about a deck. An element may be of two forms: <tag>content</tag> or </tag>. table 1 summarizes some typically used WML elements. Most WML elements have attributes that let you specify additional information about how a WAP device should interpret an element. All attribute values must be enclosed within single (') or double (") quotation marks. Character entities can be included in attribute values. WML supports both named character entities and numeric character entities. WML entities represent specific characters in the document character set. For example, the named entity & is used to represent the ampersand character (&). Note that, like XML and unlike HTML, WML is case sensitive. A valid deck is a valid XML document; thus a valid deck must be composed of an XML declaration and a document-type declaration. The high-level syntax for defining a WML deck is shown below. All cards in a deck are defined within the element. Note the use of a comment () in the WML code.

<?xml version="1.0"?>
<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN"
"http://www.wapforum.org/DTD/wml_1.1.xml">
<wml>
<card>

</card>

Examples
Given the familiarity of e-mail clients, the examples used to illustrate WML in this discussion will focus on three major use cases: (1) logging in to an e-mail server, (2) presenting a list of e-mail client menu options, and (3) sending an e-mail message.

Since the focus of this article is WML, only WML code will be used to develop the presentation component (View) of an e-mail client application for mobile devices. The Model and Controller components of this type of application (e.g., servlets, Enterprise JavaBeans) won't be discussed. However, at the end of this article there is a reference to a recent article on JavaMail that discusses how e-mail client functionality can be supported.

The code shown here was developed using the UP.SDK, which provides a WAP development environment. The toolkit includes a phone simulator with a browser that supports WML. SDKs that support development using WML can be downloaded from the sites listed in the Reference section of this article.

Login to E-Mail Server
A core use case for e-mail clients involves a user requirement to enter a login name and password for authentication purposes. This use case requires masking the password entered by a user and sending the values back to the server (Web server, servlets) for processing.

A number of WML elements are needed to support this use case. The <input> element has a name attribute that specifies the variable that a device uses to hold user input. This element also has a type attribute that masks the password (replaces the characters by asterisks) being input. The href attribute of the <go> element is used to specify navigation to a servlet for processing the user login while the method attribute of the <go> element specifies the HTTP submission method (post). The <postfield> element passes the login name and password to the HTTP server receiving the <go> request. The value attribute of the postfield element in the code below uses WML variables. For example, the value of the WML variable $pwd is substituted at runtime with the actual password entered by the user. A code snippet for entering the user ID and password is given below. A more complete code listing is shown in Listing 1.

<do type="accept">
<go method="post" href="http://localhost:8080/servlet/LoginServlet">
<postfield name="user" value="$userid&"/>
<postfield name="password" value="$pwd&"/>
</go>
</do>
<p>
Password:
<input name="pwd" type="password"/>
</p>

A simulated wireless device presentation and navigation of the two WML cards defined in Listing 1 that allows a user to log in to an e-mail system is displayed in Figure 2.

Main Menu of E-Mail Client
After logging in to an e-mail server, a user is typically presented with a list of menu options (e.g., send an e-mail message). A number of WML elements and attributes are needed to support this use case. The <select> element is used to present the user with e-mail menu choices. The onpick attribute of the <option> element specifies the card to navigate to when that menu option is selected. In this example, if the user wants to send a message, the next card shown is the card within the deck with the "send" ID. The id attribute of the <card> element specifies a name that lets you navigate to the card from other cards in the same deck. The code below shows how e-mail menu options may be presented to a user.

<card id="main">
<p mode="wrap">
My E-mail Messenger
<select>
<option onpick="#send">Send a message</option>
<option onpick="#get">Get messages from server</option>
<option onpick="#logout">Logout</option>
</select>
</p>
</card>

A display of the presentation of this WML card, showing a user e-mail menu choices, is shown in Figure 3.

Sending an E-Mail Message
From the main menu an e-mail user can create and send a simple text e-mail message. The "send" card is navigated from the main menu, as shown in the previous example. Multiple cards are needed to accomplish this use case.

The WAP phone simulator used for development has a programmable soft key. The <do> element is used to map an action to a soft key. The href attribute of the <go> element is used to specify navigation to the next card to be displayed. A code snippet from the first card used to send an e-mail message is shown below. A more complete code listing for sending an e-mail message is shown in Listing 2.

A display of the presentation and navigational sequence of the three WML cards defined in Listing 2 for creating and sending an e-mail message is shown in Figure 4.

WAP client validation of user input is an important consideration, given the inherent limitations of wireless devices. WMLScript could be used to validate user input such as an e-mail address before it's sent to a servlet for further processing. For those who have used HTML scripts, WMLScript is a procedural scripting language based on ECMAScript and adapted to suit the needs of wireless devices.

Conclusion
If you're developing applications for wireless devices, you should consider using WML to support the presentation layer of your application's architecture. WML provides a standard and extensible delivery mechanism of content for presentation on a plethora of display-constrained, WAP-compliant mobile devices. WML provides a developer with a means to focus on the content to be displayed rather than on the variety of proprietary presentation mechanisms of mobile devices. For more information on WML and SDKs with support for WML, please see the references below.

References
1. Wireless Markup Language Specification Version 1.1: www.wapforum.org
2. UP.SDK WAP Software Development Kit: www.phone.com
3. Nokia WAP ToolKit: www.forum.nokia.com/
4. Moraes, I. (1999). "JavaMail: Framework for Developing
Internet-Based E-Mail Client Applications. Java Developer's Journal, Vol. 4, issue 10.
5. WMLScript Language Specification: www.wapforum.org

Related Links

About Ian Moraes
Ian Moraes, Ph.D., is a principal engineer at Glenayre Electronics, where he works on the architecture and design of a unified messaging system. Ian has developed client/server systems for the telecommunications and financial services industries.