However, there were things going on in the text window at the same time, and we need to investigate that now. We're going to start building on the example in this chapter, so make a copy of the WML file, name it ex4_1.wml, and load it into the UP.Simulator. In the Phone Information window, this is what you should see:

From our point of view, the important information here lies between the two horizontal lines. The UP.Simulator locates the file and reports its size (244 bytes), examines its content (you should recognize the MIME type text/vnd.wap.wml from our table in Chapter 1), and then announces that the Compiled WAP binary is 151 bytes. It's that last line in particular that we're going to focus on.

The WAP Binary XML (WBXML) Content Format

We've spoken already, several times, about the importance of keeping data transfer sizes to a minimum when dealing with wireless networks, and this process of compilation is another means by which the WAP specification helps you to do that. When the word "compilation" is used in relation to computer programming, it usually refers to a process in which the instructions in a programming language are converted into codes that a computer can understand, and that's not a bad description of what's going on here.

WML files are sent to microbrowsers in a compact representation called WAP Binary XML (WBXML), and this is as true for the UP.Simulator on your desktop computer as it is for the WAP-enabled mobile phone in your jacket pocket. The difference is that under 'normal' circumstances, the WML files you write are compiled by the WAP Gateway on their way to the phone. (We talked about the WAP Gateway in Chapter 1.) On your PC, the UP.Simulator steps into that role.

The compilation of WML files is mostly a process of tokenization, in which the names of the tags and elements in your files are replaced by predefined, single-character codes. You can probably imagine that this represents a significant size saving when performed over a whole file, as names that can be up to ten characters in length are reduced to just one. When the compiled deck reaches the user agent, it is 'uncompiled', and your cards appear as you intended them to be displayed. Of course, all of this occurs without the user knowing (or needing to know) anything about it. They just get the benefit of decks appearing on their devices more quickly.

Earlier in the chapter, we mentioned the existence of a size limit for WML decks. In fact, the limit applies to compiled decks, and stands at 1400 bytes. If you see the UP.Simulator reporting a compiled size greater than that, you need to split the deck.

White Space

When we said that WML compilation is "mostly" a process of tokenization, we did so because of two other things that are affected by compilation: white space, which we'll look at here; and comments, which we'll save for the next section.

White space is a generic term for characters in your WML code that serve to break it up visually, but have no meaning as far as WML is concerned. By this, we mean things like spaces, tabs, line breaks, and so forth. As an XML application, WML inherits its parent's rules for handling white space, which are to ignore it before and after an element, and to compress all other sequences of white space into a single space between two words.

To see what this means, here once again is our sample WML document, which we've gone to some lengths to make easy-to-read. (Notice in particular the indentation before each element, the line break and space in the document type declaration, and the line breaks in the deck itself.)

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

<wml>
  <card>
   <p>Wrox Travel</p>
   <p>Welcome to our WAP site!</p>
  </card>
</wml>

As far as WML is concerned, however, we might just as well have written the code like this:

<?xml version="1.0"?><!DOCTYPE wml PUBLIC "-//WAPFORUM//
                      DTD WML 1.2//EN" 
       "http://www.wapforum.org/DTD/wml_1.2.xml">
<wml><card><p>Wrox Travel</p><p>Welcome to our WAP site!
                      </p></card></wml>

It might not look pretty, but it conveys exactly the same information, and it's 54 bytes smaller than our original version. If you load it into the UP.Simulator, however, you'll find that it compiles to exactly the same size: 151 bytes.

This means we can write our code so that it's easy to read, without worrying about increasing the amount of data being sent to the WAP-enabled device. (You can't assume that you'll always be given the job of maintaining and updating the WML you write, and even when it is you, it's a lot easier to make sense of code that's been laid out neatly.) The process of compilation applies XML's rules about white space as it proceeds.