The Wireless Markup Language is an open standard that was developed by the Wireless Application Protocol Forum, and the WML specification forms a part of the broader WAP specification. WML is an application of XML, which means that it's defined in a document type definition.

Taken together, these three facts - and the assumptions they imply - can be used to answer many of the "Why does it do it like that?" questions that often seem to be thrown at WML. The Wireless Markup Language has differences from other markup languages because it's aimed at a different target from other markup languages. If its behavior ever seems strange, that's usually down to decisions that have been made in order for it to succeed in that aim.

The Structure of a WML Application

If you've used the World Wide Web, you don't need to understand HTML in order to form an impression of how the thing works. Each web site (of which there are many tens of millions) is composed of a number of pages (of which, in total, there are literally billons). Depending on the site in question, each page will contain some information, or a set of tasks for the user to perform, or a combination of the two. In all but a very few cases, it will provide ways of moving to other pages on the same web site, and often to pages on other sites too. HTML is well suited to these purposes, and it has been an enormous success.

At face value, WML looks quite like HTML, but there are differences in the intentions of their creators. WML was designed for creating applications, whereas HTML was really designed for creating documents. The line between the two is not clean, but in general an application tends to be designed around user interaction, while documents tend to be designed around the display of information.

Another key difference between WAP and the Web lies in the hardware and software typically in use for accessing the Internet in each case. In general, the Web is accessed from powerful desktop computers that have large displays and fast, cheap, reliable network connections. The web browsing software itself is a sophisticated program that offers every possible convenience to its users. Contrast that with the relatively slow, unreliable, expensive networks available to users on the move; and then compound it with the fact that the microbrowsers (also called user agents) on WAP-enabled devices are basic by necessity, and have very small displays in which to present information to the user.

Faced with these restrictions, WML needs a different metaphor from HTML for both the type of information being sent to the user, and the way in which it's sent. Users of WAP-enabled devices are not likely to be willing to read long tracts of text in order to find what they're looking for - seldom has the adage "Time is money" been more appropriate than in the world of mobile communications. These people will come to your site seeking specific pieces of information, and they'll expect to be able to find it quickly. In those circumstances, the 'browsing' model of the Web doesn't fit the bill. More suitable is a high degree of interaction, with the user reading short 'menu' pages and answering quick questions in order to find what they need.

Cards and Decks

WML's first step toward addressing these needs is to abolish the idea of a 'page'. Instead, WML applications are composed of one or more decks containing collections of cards. Each card typically contains some content that is displayed to the user, and some other content that is used by the microbrowser to control how the user moves from one card to the next. The following diagram represents this situation, with the addition of documents, which are the files called something.wml that we'll create as we write our applications. Each of these houses a single deck.

In terms of the concept (rather than the content), a WML card is similar to an HTML page, but there is no standard way in HTML to bundle a collection of pages together. This extra facility that decks provide is important for wireless Internet applications: by bundling related cards, we can send several of them to the microbrowser at once, so that it doesn't have to ask for new cards from the server every time the user tries to move from one to another. This has the potential to save a great deal of time, and if you design your applications carefully it's possible to reduce the decks that must be transferred to a very small number indeed.

Continued...