The UP.Link platform, shown in Figure 1-1 below, provides subscribers with secure, wireless access to a wide array of Internet and other network services using data-capable wireless phones or personal digital assistants (PDAs). For the purposes of this documentation, these specially enabled handheld devices are called UP.Phones.
Using an UP.Phone is much like using a conventional Web browser. The user presses keys to navigate and request URLs. Unlike standard browsers which use the Hypertext Markup Language (HTML) to display information on a computer screen, UP.Phones use the Wireless Markup Language (WML), an open language developed by the Wireless Application Protocol (WAP) Forum1 to accommodate small handheld devices. Like HTML, WML is tag-based and supports text and image presentation, data input, and forms.
The UP.Phone uses the data capabilities of conventional wireless networks to send user requests to the UP.Link Server. The UP.Link Server converts these requests into Hypertext Transport Protocol (HTTP) requests and forwards them over the Internet. When the target service responds, the UP.Link Server relays that information back to the UP.Phone.
The UP.Link Server is the core of the UP.Link platform. Its ability to serve as an HTTP proxy for UP.Phones lets subscribers access any site on the World Wide Web. Some information providers also offer WML services that use WML to take advantage of the UP.Phone interface. These services can also initiate communication by "pushing" information to the UP.Link Server, which, in turn, relays it to an UP.Phone. This process is called notification.
In addition to HTML translation, the UP.Link Server provides a number of other services. It acts as an information gatekeeper by maintaining a database of UP.Phones and their access privileges. It provides optional fax services that let UP.Phone users fax Web site content (including text, Microsoft Word, and Postscript files) to a local fax machine. It also provides configuration parameters that allow administrators to monitor or log transactions.
The final component of the UP.Link platform is the UP.AppsTM suite of WML services. These packages are optional and consist of the following:
UP.Mail, an email system that lets subscribers send, receive, and save email.
UP.Organizer, a Personal Information Manager (PIM) that provides subscribers with integrated calendar, address book, and To Do list tools.
UP.Web, a service that offers subscribers a Web-based interface for performing many of the same tasks they do using their UP.Phones.
UP.Directory, a tool that lets UP.Link operators create directories of WML services that subscribers can access using either their UP.Phones or UP.Web accounts.
Although UP.Phone user interfaces vary, all UP.Phones have the following features:
A display with a minimum resolution of three lines of twelve fixed-width characters.
Support for text entry. UP.Phone models typically allow users to enter text by pressing the number keys.
A minimum of two programmable user interface mechanisms--called ACCEPT and OPTIONS. Some UP.Phone models implement ACCEPT and OPTIONS with function keys; others implement them with a jog shuttle or context-dependent user gestures. Users activate the ACCEPT mechanism to acknowledge a message or confirm a choice; they activate the OPTIONS mechanism to display context-dependent information or options.
A mechanism for backing up--called PREV. Many UP.Phones have a dedicated key for this function, typically labelled with a left arrow or the word BACK.
WML is a markup language based on Extensible Markup Language (XML). XML, like HTML, is a Standardized Generalized Markup Language (SGML) variant. The WAP Forum provides a formal Document Type Definition (DTD) for WML at:
http://www.wapforum.org
The WML language defines elements and attributes that let you specify the user interface components, called cards, that users see on their UP.Phones. Just as a Web browser can navigate from one page to another, the UP.Browser can navigate from one card to another.
A card can specify multiple user actions by including one or more of the following:
Formatted text--including text, images, and links
INPUT elements--which let the user enter a string of text
SELECT elements--which let the user choose from a list of options
FIELDSET elements--which act as organizational containers for other elements
The smallest unit of WML you can send to an UP.Phone is a deck--one or more cards that a user is likely to access together. When an UP.Phone receives a WML deck, it displays the content defined in the first card and allows the user to respond. Depending on the card definition, the user can respond by entering text or choosing an option. UP.Phones with larger displays typically present each card as a single screen. Some smaller devices present each card as a collection of screens.
The following WML statements define a simple deck. The deck contains a single card that displays a line of text:
1 <?xml version="1.0"?>Lines 1-3 represent the document prologue. Like all XML documents, a WML deck must contain both XML and document type declarations. Line 1 (the XML declaration) specifies the XML version. Lines 2 and 3 (the document type declaration) identify the file type as WML and specify the location of the DTD to use for compiling the file. You must include these lines in every WML deck.
Line 4 is the deck header.
Lines 5-8 define a card that displays the text "Hello, Unwired World!"
Line 9 is the deck footer. The UP.Browser treats everything between the deck header and the deck footer as a single WML deck.
Loading this deck displays a screen similar to that shown in Figure 1-3.
Through a set of Openwave extensions to WML, the UP.Browser 4.1 provides a migration path from existing HDML applications to WML:
spawn
exit
throw
catch
send
receive
reset
link
accesskey
These extensions allow WML applications running on the UP.Browser to create nested contexts, which simplify user navigation and provide local/protected scope for WML variables. In addition, images may be displayed within 'select' list options or as the labels for 'do' elements. For more information, see the WML Language Reference and the UP.SDK Developer's Guide. Implementation details are provided in the sample CGI applications in: examples\scripts.
NOTE All Openwave extensions to WML have been formally submitted to the WAP Forum as change requests for the WML specification.
If you use these extensions in your WML content, you must include the following DOCTYPE header in the WML deck:
<!DOCTYPE wml PUBLIC "-//PHONE.COM//DTD WML 1.1//EN"
http://www.phone.com/dtd/wml11.dtd" >
IMPORTANT Applications can make use of these extensions when accessed by a phone running UP.Browser 4.0 or higher. To identify the WAP browser type and version, capture the WAP-standard USER_AGENT header in the HTTP request. See the whoami.cgi example for implementation details.
WMLScript 1.1 provides general scripting capabilities to the WAP architecture. Specifically, WMLScript can be used to complement WML, which is designed to be used to specify application content for narrowband devices like cellular phones and pagers. This content can be represented with text, images, selection lists, and so on. Simple formatting can be used to make the user interfaces more readable as long as the client device used to display the content can support it. However, all this content is static and there is no way to extend the language without modifying WML itself.
WMLScript was designed to overcome these limitations and to provide programmable functionality that can be used over narrowband communication links in clients with limited capabilities. For more information about WMLScript, see the WMLScript Reference.
WML services are Web applications that return WML and other content in response to HTTP requests. While static WML decks can comprise a WML service, generating WML content dynamically usually provides more meaningful information for users (for example, securities trading, order tracking, or traffic reporting systems).
Like conventional Web applications, WML services can generate screen content dynamically by using CGI (Common Gateway Interface) scripts or Web server APIs to query databases or other external data sources.
WML services can support both push and pull transactions:
Push transactions send information (notifications) to the UP.Phone asynchronously, i.e. independent of any interaction with the user.
Pull transactions transmit information in response to a user request.