Ever wonder what your Web page looks like on a cell phone? Delivering data applications and Internet content to mobile devices is one of the hot spots on the technological landscape right now. One reason this technology is taking off is because all of the significant industry players joined together to back a common standard for mobile data, the Wireless Application Protocol (WAP). Included in the WAP specification are the Wireless Markup Language (WML), and the WMLScript scripting language, which serve analogous functions to the Web's HTML and JavaScript.
As predictions concerning mobile Internet use continue to skyrocket (like a recent Cahners In-Stat study that promises 1.3 billion wireless data users by 2004), opportunities in developing wireless content will grow rapidly. Now is a great time to become familiar with the tools being used to craft the wireless Web.
Martin Frost is the author of Learning WML and WMLScript, a new book that describes the markup and client-side scripting languages used for delivering content to wireless devices. Martin is the head of WAP technology at Digital Mobility Ltd. in London, and has been working with WAP since 1998. Writer Bruce Stewart talked to Martin about the book, WML and WMLScript, and the future of the WAP model.
|
Related Reading 
Learning WML, and WMLScript |
To make it easier for developers to learn the WAP standards, they are based on a model very similar to the Web, which uses HTML to create pages of formatted text, and JavaScript to add dynamic features.
WML is WAP's equivalent of HTML. It allows text to be marked up with paragraphs, hyperlinks, text input boxes, and so on, but in a way that optimizes the content for small screen sizes.
Similarly, WMLScript replaces JavaScript in the WAP world. It allows simple client-side checking of input, but is much simpler than JavaScript and is considerably less demanding on the device.
Another effect of XML is that empty-element tags, which are tags that don't have an end tag, must be written with an extra slash like:
<br/>whereas in HTML this would look the same as a start tag
<BR>A lot of HTML contains syntax errors that are ignored by Web browsers, but will cause problems for WAP browsers. Many people forget the quotes around attribute values and miss the semicolons off the ends of entities, and both of these mistakes will cause the file to be rejected by most WAP browsers, even though Web browsers will attempt to ignore the error.
WML also includes several new features that aren't found in HTML, most notably in its support for interaction. HTML evolved over some time to include new features: interaction was initially limited to just hyperlinks, then Netscape added forms with checkboxes, text input and so on, and JavaScript was added later still. WML has a different way of approaching these things, which is more elegant and consistent but may take some getting used to. This new approach is discussed in detail in my book, Learning WML and WMLScript.
In WML, the control is separated from its action, so there is a thing called a "task". This is simply an action to be performed by the browser, such as going to a new place, running some WMLScript, and so on. This task is then linked to the actual control--the task is just another tag, so it's placed inside the control.
This means that you can have a hyperlink which does a POST, a button which runs some WMLScript, and you can also link these tasks to other things like a timer that goes off after a certain amount of inactivity, a particular option being selected from a list, and so on. It all just helps to make these things more consistent. You learn how to write tasks once and then it works in all these places.
A Web page is basically a continuous stream of content. You can put labels into it and jump to particular places, but all you are doing is scrolling to fixed places in the stream.
WML treats its files as analogous to a stack of cards, each of which has separate content. Instead of a label merely referring to an offset in a continuous stream, the label names a card. There is no way to get from one card to another simply by scrolling--there must be an explicit link to a card. The idea was to minimize the need for scrolling by keeping the amount of information on a card small and presenting information on a sequence of separate cards.
In practice, most programmers don't use this feature as much as they maybe should.
Some features, such as tables and image alignments, are supported only by a select few WAP browsers, but usually won't actually break anything seriously if they are used. The display may look wrong, but it may still be usable.
A few months ago I would have recommended not using WMLScript at all, but the situation has improved enormously. A number of browsers have trouble with some standard library functions, but it seems that the test suite is gradually doing its job and weeding out the bad implementations.
The main thing to bear in mind is that you should avoid relying on the letter of the specification for things like boundary cases in libraries until the browsers get more mature.
The test suite is used for two things. While a WAP browser is being developed, it can be tested regularly against parts of the test suite to find any bugs in it. Once it's ready for release, the whole test suite is run, and this is used by the certification process to ensure that the browser really is compatible with the standards.
The latest WAP test suite can be found at www.opengroup.org/vswap1.1.4/.
It really depends on who you are. If you trust whoever's running the gateway, it's not a problem.
Most security experts are very paranoid--it comes with the territory. They are also invariably perfectionists, and the idea of having this extra point of weakness is not something they are happy with. They are interested in designing systems where you don't have to trust anyone, because even a respectable company can be forced in court or by a government to reveal private information, and the gateway may be vulnerable to a cracker.
The other main area of concern is from banks and other financial institutions, since the main real reason for WTLS is to allow mobile financial transactions. Most banks don't really understand computer security--if they did, they wouldn't pay so much to all the self-proclaimed experts. They do, however, have very strict procedures about what risks are and aren't acceptable. Their rules say that the private data must not be accessed by any outside party, so they don't like the gateway operator having this information in the clear, even if it's only buried deep in the guts of the gateway software.
Writing a WAP gateway isn't too hard. There are some problems with the specifications containing errors, and there are some parts where implementing the specification literally can cause problems, but it's more an engineering exercise than anything else. Most of the techniques are fairly standard for using in any high-performance networking system. Studying the design of a well-written TCP stack or something similar will give you most of the clues you need.
As to why we wrote our own, we needed the gateway to integrate tightly with the company's proprietary application server architecture because we wanted to provide a seamless user experience, with the ability to reconnect later and pick up where you left off, and so on.
Another consideration was that we wanted access to the source so that we could fix problems quickly, rather than having to put customers off with, "Sorry, but our gateway supplier hasn't sent us the patch yet." At the time we started on the project, the open source gateway wasn't really in a usable state. We considered it, but decided that we could do a better job ourselves.
Most high-end PDAs already support normal Web browsing, and that will always stay. Most current PDAs either have WAP as an option or the supplier is working on it. So this fraction will increase.
The situation is different with cell phones. In Europe, there is at least one phone from every major manufacturer with WAP, and many manufacturers are working on retrofitting WAP into the older models that they plan to continue. In the U.S., there are still cell phones available using Phone.com's proprietary HDML system, and this has held back the adoption of WAP.
The fragmented nature of the U.S. telecom market doesn't help much, either. There are many different systems, and still even some analog networks! All of Europe uses GSM, which means that there is only one standard for phone manufacturers to contend with, and only one version of the phone software that has to have WAP integrated into it. These problems mean that WAP will take longer to take off in the U.S.
As to actual percentages, I really can't comment. Various people have quoted widely varying statistics on adoption, and I prefer to leave making quantitative judgments to the statisticians!
In its current form, no.
i-Mode is quite closely tied into DoCoMo's network. It uses data capabilities only found on that network.
I also think that other operators would be unwilling to embrace i-Mode wholeheartedly and thereby give a large amount of power and influence to a single company. The advantage of WAP is that the specifications are published by the WAP Forum, a body which anyone can join--although there is quite a steep joining fee.
A number of companies have made loud public statements that WAP is dead and i-Mode is the future, but I think most of them are just desperately flailing around, trying to regain the initiative. The amount of investment that has been put into WAP gives it a huge head start on any other system for now.
Finally, i-Mode really isn't all that special. It uses normal HTML and sound and image files. Apart from the details of the actual over-the-air communication, the only new part is the compressed form of HTML that they use. WAP has an equivalent to this that works for other XML documents, as well.
There are some useful lessons to be learned from i-Mode about the sorts of applications that are useful and successful in a wireless environment, but most of these lessons are applicable to pretty much any system, including WAP.
Higher bandwidth will not kill WAP, it will simply enable richer content and a better user experience. It may well be the case that some parts of WAP, like the special communications protocols optimized for low bandwidth, will become redundant and can be replaced by regular HTTP.
The future for WML is more interesting. The WAP Forum has announced that the next-generation of WAP will be based around XHTML, which is the W3C's appointed successor to HTML, and based on XML in the same way that WML is. However, this is still a long way off.
In addition, WML will continue to have a place in cell phones for some time, even once XHTML starts being used. The fact that WML is optimized for small screens means that it will continue to perform better than alternatives, even with lots of bandwidth. Even if it's possible to get a phone with a multi-megabit link, many people will still want small phones, because of their convenience.
Just think of the people you know with cell phones now. Even though there are phones available with big screens, how many people use them compared to the smaller, more convenient ones? XHTML content designed for big color screens will come out poorly on these devices, but WML works just fine!
Martin Frost is the head of WAP technology at Digital Mobility Ltd. in London. He has been working with WAP since 1998, and has written a complete WAP browser and worked on the design of a WAP gateway. He has a degree in math and computing from Imperial College, London. He spends his free time reading, playing cricket, designing ever more elaborate schemes to wire up his home and his car, planning world domination, and trying to find time to actually do all these things.
|
Related Reading Learning WML, and WMLScript |
Copyright © 2009 O'Reilly Media, Inc.