WML Overview

In the next section, we discuss the concepts behind WML and the syntax rules governing WML, and we introduce the most unique aspect of WML—its "card" and "deck" navigational structure.

Concepts

Since WML uses an XML vocabulary, it would be useful to understand some basic principles of XML (Extensible Markup Language), a tag-based system used for defining, validating, and sharing document formats. Although they are very similar, WML differs from XML in the following ways:

• WML's white-space handling rules are not as elaborate as XML's.

• WML relies on well-formed expressions.

• WML has a built-in method for handing international characters.

If you are already familiar with the requirements of XML, you might find some portions of the section below repetitive. However, you may want to read through it anyway as the section covers issues specific to WML which are not generically part of XML.

Syntax Rules

WML is like a strict grammar teacher. You will be punished if you do not strictly adhere to the rules set before you. In the next section, zwe will show you how to be successful in meeting WML's demands to build a working WML application.

Character Sets

WAP, as a protocol, has already found international acceptance. As such, certain international characters are supported, and characters such as tildes (~) and ampersands (&) need to be visible to users.

By default, WML pages use the ISO-10646 character set. In fact, if we were being syntactically perfect in writing our WML code, we would always state this specifically by including in the XML definition at the start of every deck:

<?xml version="1.0" encoding="iso-10646"?>

The ISO-10646 character set is the computer industry's fancy name for the Unicode character set. This should give you all the basic international characters, but if you need to support a different ISO standard character set, you can adjust this header.

Much like HTML, WML has some reserved characters. For example to print a > in HTML, you would actually escape-code the character and put &gt in the HTML code. This holds true for WAP as well. In WML, certain character references are widely supported. These are shown in Table 2.2.

Additional characters are also supported through standard escape coding. For example, the word café would be written as caf&#233, where decimal character 233 in the ISO-10646 character set is the letter é.

For additional information, we recommend you take a look at the Character Entity Reference Chart available online at the World Wide Web Consortium's Web site at http://www.w3.org/International/O-charset.html.

White Space

As mentioned earlier, WML differs from SGML quite significantly when it comes to handling white space. In general, if a user were to transmit SGML, all the irrelevant characters would be removed. This is not the case with WML. WML in most incarnations will transmit all the characters in the WML file and then rely on the client device (be it a WAP browser, Web browser, or another application) to display the information in the proper manner, removing irrelevant white spaces; otherwise, line breaks, tab characters, and regular spaces get passed to the application.

Programming Considerations

As we mentioned earlier, WML is syntactically oriented and relies on well-formed code. This means that as developers, we need to be concerned with our spacing of characters when we write in WML. For example, in WML, you must space value pairs with a space, but you cannot use white space between an attribute, the equals sign, and the attributes value.

<access
     domain="dsn"
     path="wapdir"
>

The previous example is well-formed. The following example, however, would generate errors because of the spaces surrounding the = symbols.

<access
     domain = "dsn"
     path = "wapdir"
>

Likewise, we cannot run the attributes elements together as below:

<access
     domain="dsn"path="wapdir"
>

This code would create an error.

WML does make special considerations for the quote characters. Under HTML, the standard evolved ad hoc to correct common errors made by programmers. For example, under Internet Explorer 5.0, the commands

<table width="100%">

and

<table width='100%'>

have the same effect. This programming standard has held true for WML as well. In general, it is preferred to use this syntax:

<p align="right">

But, it is acceptable to use this syntax:

<p align='right'>

Remember that WML is particular about white space, but at the same time, it is important to adhere to standard coding conventions. For example:

     <p>
          E-mail $emName<br/>
          Subject: <input type="text" name="subject"/><br/>
          Message: <input type="text" name="message"/>
     </p>

This code adheres to standard coding conventions of indenting various nested levels. In this case, we see the paragraph's contents are indented further. In WML, it is important that each tag has a match and the nesting order is appropriate. In HTML, we could get by with syntax like this:

<B><I>Hello World</B></I>

However in WML, strict adherence to nesting levels is required and closing the bold tag before the italics tag would generate an error. Therefore, the only way these commands could work is through the syntax:

<b><i>Hello World</b></i>

Case Sensitivity

WML is like a grammar test. Any punctuation, any misspellings, and any case-sensitive mistakes will cause the compile to fail. This is particularly true when you consider start and end tags. In HTML, a valid tag match might include <BODY> and </body>. However, in WML, <IMG/> and <img/> would indicate two different start and end tags.

Variables follow the same logic regarding case sensitivity.

     Variable1
     variable1
     VARIABLE1

All the previous examples are different variables in WML, and each could have a discrete value assigned to it.

Required Prologue

The WAP server and WML compilers need to have a manner by which they can reference the XML specification. To do this, XML requires a prologue that defines the XML version and a pointer to the XML definition or language being used. Most of the examples we refer to for the remainder of this book will use the standard prologue:

<?xml version="1.0"?>
<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.2//EN"
"http://www.wapforum.org/DTD/wml12.dtd">

In general, a WAP device will never see this prologue, as the server and compiler are the only two devices that care about the definition of the XML format.

For the sake of brevity, the prologue will be left out of our code examples in this book with the exceptions of the upcoming deck examples.

WML Components

When developing for the Web, each HTML file constitutes one HTML page. Developing in WML is slightly different. Because each page or screen is very small, it does not make as much sense for each page to constitute a separate file. WML pages—content viewed on separate screens—are called cards and those cards are all placed within a deck of related pages which constitute one single file.

Decks

When HTML is transmitted to a Web browser, we consider it to be an Internet document. A deck is the simplest wireless document. It consists of the same basic elements you would expect to see in an HTML document: prologue, WML tags <wml>, header tags <head>, and a few other tags unique to WML. Each deck has a series of cards in it. Therefore, the goal of WML due to wireless limitations is to keep decks small, and occasionally have a few decks in a single WML application.

Cards

Inside each deck are one or more cards. The cards are the drivers of the application. Each card defines how a particular screen looks, how that screen functions, and what steps are taken when the card is navigated. As such, a card can never be empty and must contain at least one element. The information inside the elements derive either content or navigation instructions.