Have you written any wireless applications yet? If you haven't, you soon will be. If you read the estimates from the professional research firms and forecasters, you'll see they tend to agree that wireless advertising, and ultimately mobile commerce (m-commerce), will become huge industries in the next four to five years.

The projections from The Kelsey Group, Ovum, and Durlacher of London estimate that wireless advertising revenues will reach between $16 billion and $23 billion by the year 2005. That's up from estimates of $210 million for the industry in 2000. The same study mentions that by the end of 2003, there will be more than 70 million wireless Internet devices used in the U.S. alone, so be ready.

This is a huge wave coming our way. We can ignore it - and let it crash on top of us. Or we can get the surfboards out - and ride this big one in. So what kind of wireless server should be used? If you're already using Jaguar, look no further. This article focuses on wireless basics. Actual Jaguar configuration will be covered next month.

I'll assume you know a little bit about how to write wireless application and instead focus on how to use the Java APIs for XML Processing (JAXP), along with XML Styleheet Language Transformation (XSLT). In English that means I'll show you how to build content the wireless device can understand. For those of you who are beginners in this area, I'll start out by explaining the basics.

Screen Resolution
Back in the old days (does anyone remember 1994?), the cutting-edge technology was client/server GUI development, with languages such as Visual Basic or PowerBuilder. One of the problems with early GUI development was you never knew which monitor resolution to program for. If the application was viewed on a monitor using 800x600 resolution, it wouldn't fit on desktops using a lower resolution. If the monitor resolution was high, your applications were too small to see.

Internet development partially solved this problem. By using markup tags to define the GUI, the application could use more of a relative as opposed to absolute positioning - meaning the GUI would resize somewhat when the user resized the browser. By default, Java applets also use this system of relative positioning.

So what's the point? As you'll find out, screen resolution problems are even a larger issue on handheld devices. High-end PDAs, such as the Handspring Prism, have a resolution of 160x 160 pixels. A far cry from traditional monitors that have a resolution of five times this much. Mobile phones are on the lower end of screen resolution. A Nokia 6185i has only five lines of resolution. So what do you do? Write completely different applications for each device?

That's not feasible. After a while your code will get as fat as Charles Barkley. As you will learn later, you can use JAXP/XML/XSLT to regulate what content gets served to which devices.

Browser Differences
With few exceptions, wireless applications are run within a microbrowser. These browsers come in all shapes and sizes, but all have the same purpose: to connect to the Internet. So with that in mind, a microbrowser serves the same purpose as its larger, full-featured cousins, such as Netscape Navigator and Internet Explorer. Like its cousins, a microbrowser may have varying support (or no support at all) for certain markup tags.

In a nutshell, just because a wireless application will run on one microbrowser doesn't guarantee it will work on others. To further complicate your day, there are currently dozens of microbrowsers that are being used. Your job is to make sure your wireless application works in all of them. Again JAXP/XML/XSLT will help you with this daunting task.

XML in General
Remember XML is a set of markup tags that describe the data - not the presentation (what the user sees). Almost never does the user see pure XML. XML is an intermediate technology that is transformed into viewable presentation tags, such as WML or HTML. Where does the XML come from? Just about anywhere you want. It could be in something as sexy as a Java byte stream or as mundane as a flat file. Keep in mind that just because XML is a new(er) technology, any language that can write flat files can generate it (COBOL programmers are allowed to snicker here). For the sake of simplicity, I will use XML in the form of a flat ASCII (read Notepad) file.

Transformations in General
When XML needs to be viewed, it has to go through a transformation. The transformation refers to reading the raw XML file, then stripping the XML tags and replacing them with markup tags that can be understood by the browser. In the case of traditional browsers such as Internet Explorer, HTML tags will be used. In the case of microbrowsers, WML tags will be used. The beauty of transforming XML to the desired markup language is that only a single XML file is required. The resulting data can be formatted differently depending on which browser is requesting it.

So what defines the transformation? Not surprisingly, you define the rules of the transformation. How you do this can vary, but for the sake of simplicity, this article will place the transformation in a flat ASCII file. Most transformations are performed on the server in this fashion. Files that define the transformation rules are called stylesheets and generally have an .xsl or. xslt extension. Let me start with simple examples of transformations, then I'll get more complex as I go into detail. Before I can explain how and where transformations take place, I need to first explain some syntax.

Rules of Transformations
For the remainder of this article, I'll use the following XML file (see Listing 1). As mentioned previously, this file could have been generated from anywhere. How it's generated is up to you. As long as it exists as a well-formed (syntactically correct) document, the examples will work as advertised.

Before I get into the details of transforming this XML file, let me clarify some definitions. The XML file mentioned earlier will be used in all of my examples.

It begins at the top with the root node, which contains one child node: the root element BRADYS. The BRADYS element contains three child nodes, all BRADYGIRL elements. Each BRADYGIRL element has a variety of child element nodes - describing important details about each BRADYGIRL. Each child element contains a node for its contents. The relationship between nodes and elements is important because the eventual transformation is based on this tree structure. A tree is a data structure composed of connected nodes beginning with a top node called the root. The root is connected to its child nodes and only one root element, which is connected to zero or more children of its own, and so forth. If a node has no children, it's called a leaf. There are no leaves in this example.

The next step is to apply the tranformation to this XML document, as mentioned previously. I'll get into the details of applying the stylesheet a bit later. For now, let's focus on the transformation syntax. Take the following stylesheet (see Listing 2).

The first thing that needs to be explained is the template. The template rules that are defined by the xsl:template elements are the most important part of any XSLT stylesheet. The template is responsible for mixing XSLT functionality with actual markup tags and content. All XSLT instructions are in the www.w3.org/1999/XSL/Transform namespace.

It's easy to distinguish between the elements that are literal data to be included in the output from the actual instructions. The stylesheet in Listing 1 contains a template that is applied to the root node of the input tree of the XML file. In addition, each xsl:template element has a match attribute that specifies which nodes of the XML document the template is applied to.

In this example, the template is executed when the root node of the XML document is found (denoted by <xsl:template match="/">). The root node comes immediately before the root element (in this case BRADYS). There are no further instructions in this template, so its contents will be copied verbatim. The result of this transformation is displayed in Listing 3. Note that our transformation will not yet display anything to the user.

With the basic HTML tags out of the way, the next step is to add other template rules to process the child nodes (in this case BRADYS and BRADYGIRL). Take a peek at the stylesheet in Listing 4. Let's walk through the transformation one step at a time.

First, the stylesheet identifies the root node. This isn't hard because all XML documents have a root node just before the root element. At this point <html> is written out. The next line <xsl:apply-templates/> then branches, processing to the next </xsl:template> instruction. The <xsl:template match="BRADYS"> is encountered. The transformation then looks for a node named <BRADYS>. It finds it, then writes out <body>. The next line <xsl:apply-templates/> branches, processes yet again to the next </xsl:template> it encounters. Here the line <xsl:template match="BRADYGIRL"> is executed. Since we have just branched from the <BRADYS> node, the template match is looking for all <BRADYGIRL> nodes that are children to "BRADYS>. The three <BRADYGIRL> nodes are found and the text "Brady Girl Found" is written out - with a line break between them. Processing then returns to the <BRADYS> node where </body> is written.

Finally, processing goes back up to the root node, where </html> is written. You may have to go through this example several times before it sinks in. To make things easier, remember that stylesheets don't execute in a top-down fashion. They execute recursively. Because of this recursion, it should start to be clear why XML must be well formed. It must be well formed or it would be impossible to process. Listing 5 shows the results of the tranformation using the three template rules.

The preceding example provides a good example of how the stylesheet recursively processes the XML file. However, as you can see, the output is not too useful. What is really needed is a way to display the data value of an XML tag, not a "hard-coded" value as in the previous example. This can be achieved by using the xsl:value-of element. This element will search for the data value of an XML tag, then display it in the output document, in this case an HTML file. The select attribute of the xsl:value-of element searches for the value of a specific XML tag in the current node. In the preceding example, if I wanted to replace "Brady Girl Found!!!" with the first name of each girl, I would add the line xsl:value-of select="FNAME"/> to my stylesheet (in Listing 6, changes are in bold).

The above stylesheet generates the following HTML as seen in Listing 7. Note the <BR/> tag is in XML format rather than the HTML <BR>. This is because XML doesn't support empty tags (start tags without end tags).

The above approach works well when you know the name of the tag you want to display. But what if you're not sure of the name of the tag? Or what if you want to display the value for all tags for a specific node? In this case, use a period to denote this. The element <xsl:value-of select="."/> means "display the value of all tags in the current node." This approach is especially useful if there are so many children in the current node it would take forever to type them in. Therefore, the two code examples (see Listing 8) will produce the same output.

Another way to "loop" through all tags is by using the XSL for each element (see Listing 9). This element can be used without a template if any (or all) tags in a node need to be displayed in the output document. This syntax will display the identical output as the stylesheets in the previous code example. The only difference here is that two template rules are now being handled by one template. The HTML file generated by the following stylesheet can be found in Listing 10.

Where Does Transformation Take Place?
The actual transformation can take place at the client or at the server. A client-side transformation occurs when an XML file and stylesheet (XSLT) are both served to the browser. In this case the browser (in theory) has the intelligence built in to perform the transformation. For this to occur, a single line must be added to the XML file to indicate which stylesheet to use for the transformation (see Listing 11). It's important to point out that at the time of this writing (and for the foreseeable future), Internet Explorer 5.5 is the only browser that supports client-side transformations. And in a typical Microsoft move, they don't support the accepted XSLT standard but its own version of the standard.

What does that mean for you? It means that if you're using IE for client-side transformations, don't expect it to always work with standard XML/XSLT. In any event, Listing 11 lists the tweaked XML and stylesheet so that it can work in an IE client-side transformation. If you'd like to test it, save both files in the same folder, then within IE open the XML file. The resulting transformation (HTML file) should be displayed in your browser.

Server-side transformations occur when the stylesheet and the XML file both exist on the server. The server is responsible for applying the transformation, then sending the results to the browser. In practice, this is the most common way to perform transformations. Server-side transformations make more sense over client-side transformations. When the transformation takes place on the server, you don't have to worry about the browser's XML compatibility since you are serving pure markup tags and content.

Server-Side Transformations
In the context of this article, I'll use JAXP (Java API for XML Processing) by Sun Microsystems. For our purposes this is an excellent choice because it's written in Java and can be easily implemented in a servlet. To obtain the JAXP, go to http://java.sun.com/xml/download.html. Here you'll find the JAR (Java Archive) files to download as well as valuable documentation. There are detailed installation instructions, so I won't repeat them here. One thing I'd like to emphasize (that's not clear in the installation instructions) is that the files servlet.jar and jaxp.jar must be in the folder that contains the Java extended libraries. On most computers this folder is c:\jdk1.3.1\jre\lib\ext. The file servlet.jar is not found in the JAXP download. To get it you must first download the Java Servlet Development Kit (JSDK) at the address http://java.sun. com/products/servlet/download.html. Also, make sure these two JAR files are in your Java-enabled Web server's library path. See your Web-server documentation for details. The location may differ slightly.

Finally, I need to point out that JAXP is large and contains much functionality that I have not discussed here. Transformations (XSLT) are only a small part of what JAXP does.

Writing the Program
Adding the transformation functionality to the servlet is a snap. Understanding the transformation syntax is the hard part. Now that you have the basic syntax mastered, the final piece is to programmatically specify the XML document with its stylesheet.

For the purpose of this article I'll assume you know the servlet basics, so I will not discuss them in detail here. Listing 12 includes the servlet that will transform the XML file. Code related to the transformation is in bold for readability. In a nutshell, the XML and XSL file are supplied.

Next I specify that the transformation be sent to the requesting browser. The line of code transformer.transform(xml,result) is where the actual transformation takes place. The XML file referred to in Listing 12 is the same one I've been using throughout this article. The stylesheet used is listed in Listing 13. Notice the basic guts of the stylesheet remain untouched. I just added more realistic markup tags to dress up the transformation. The HTML markup tags are in bold and the transformation instructions are left in regular type. The result of the transformation is displayed in Figure 1.

Wireless Devices
As I pointed out at the beginning of this article, XSLT is useful for wireless devices. The preceding example uses transformations that contain HTML. What if the browser doesn't understand HTML but does understand WML (or any other markup language)? The XML file need not be changed. Just be sure to have a stylesheet that serves WML tags. The stylesheet in Listing 14 transforms the XML document into WML. The WML markup tags are listed in bold. The resulting WML transformation is displayed in Figure 2. This is approximately what the output would look like on a PDA or a phone.

Remember that your servlet must be changed so it can determine which stylesheet to serve. The updated servlet is displayed in Listing 15. Changes are in bold.

Final Words
There you have it. As you can see, using JAXP in conjunction with XML/XSLT can provide flexible front ends to a variety of devices. Just remember that you need to create a new stylesheet for each and every markup language you want to support. And with XML, you can bet there will be a lot of new markup languages coming.

• Figure 1
• Figure 2
• Source Code