Microbrowsers

Wireless Content Types

The creation of wireless Internet applications involves many types of content, including markup languages, images, multimedia, and business oriented files. For most phone-based applications, such as those using WAP, you will only have to be concerned with the wireless markup language and some basic images. But if you are targeting higher-end devices, such as those based on Windows CE or Symbian OS, you will have the option of incorporating multimedia content and business files, such as Microsoft Word or Excel, into your applications. The content types that are supported will be dictated by a combination of the microbrowser and the mobile operating system being used.

In this section we are going to focus on wireless markup languages. The markup language controls the majority of the application, including the user interface, navigation, and content.

We are not going to focus on the other content types, as they vary significantly among devices and microbrowsers.

Markup Languages

When developing desktop Internet applications, HTML is the markup language of choice. If a developer is comfortable with programming HTML, he or she will be well prepared to create content for all of the leading browsers, including Internet Explorer, Netscape, and Mozilla. Unfortunately, this is not the case in the wireless world, where HDML, WML, HTML, cHTML, and XHTML are all used for various browsers. The factors that contribute to which markup language will be required in a given development effort include geographic location, device type, and the microbrowser being used.

This section provides an overview of each of these markup languages to familiarize you with the main concepts of each language and where each is commonly used. To help demonstrate these, we will also look at some sample code.

Note 

The goal of this chapter is to give you a feel for language concepts in general, not to teach the in-depth workings of each language. The sample code is the first screen of an inventory application, where users can select how they would like to perform an inventory search. It is included for illustrative purposes only; these samples are not intended as complete applications.

Later in this chapter, we will take a look at the various content-generation technologies that can be used to create data-driven wireless thin client applications.

HDML

For those developing applications exclusively for markets outside North America, the Handheld Device Markup Language (HDML) is not important. Device manufacturers outside of North America did not ship HDML-based devices, but instead moved directly to WML devices. If, however, you are going to be deploying to users in North America, and you will not have control over the devices being used, you will want to read about HDML.

In 1997, Unwired Planet (now Openwave, and Phone.com in between the two) developed HDML, along with an HDML microbrowser called the UP.Browser. This took place before WAP came into existence, meaning that WML did not exist either. The idea behind HDML was to create a markup language that was suitable for use on cellular phones. (At the time, XML was quite new, so Unwired Planet did not base HDML on XML, thereby imposing limitations it could not foresee.) For the most part, the structure of HDML is loosely based on HTML, but it does not have anywhere near the capabilities that HTML offers. HDML is really a transition technology. As just stated, it was used before the advent of WML, which now has much wider industry support, and is deployed on a much larger scale.

Note 

The full specification for HDML can be found on the W3C Web site, www.w3.org. It is still in working draft format, and has not been enhanced since its inception. This is a clear indication as to what the future holds for HDML.

Another limitation of HDML that is often considered an impediment to development is its lack of scripting capabilities. It does not support JavaScript or, like WML applications, WMLScript, making HDML quite restricted for executing logic locally on the device. Tasks such as validating user input, generating messages and dialogs, and other device-specific tasks can often be accomplished using HDML, but they have to be driven from the server, rather than the client. This increases network traffic, thereby reducing performance.

That said, HDML is still used in the U.S. and Canadian markets, primarily on CDMA- and CDPD-based devices. All North American devices that shipped before the end of 2000 used HDML-based browsers; so, as you can imagine, millions of these devices are still in use, and most likely will be for a few years to come. Fortunately, many of the WAP gateways will convert HDML to WML for you, making HDML content viewable on WAP-enabled devices. In addition, converting HDML to WML manually is not a difficult task, so you should be able to reuse many of your HDML applications once they are no longer required.

HDML Example

Let's take a look at some HDML code to get a feel for what it looks like. In Listing 13.1, you can see some straightforward HDML code that produces a list of choices when presented in an HDML browser, as shown in Figure 13.1.

Figure 13.1: Openwave HDML Emulator showing output from sample code in Listing 13.1.

Listing 13.1: HDML code for inventory sample.

 1. <HDML VERSION="3.0"> 2.   <CHOICE> 3.     <CENTER><b>Inventory Search</b> 4.     <CE TASK="GO" DEST="#ProductSearch">Search by Name 5.     <CE TASK="GO" DEST="#SKUSearch">Search by SKU 6.     <CE TASK="GOSUB" DEST=inventorylist.jsp>Inventory List 7.   </CHOICE> 8.   <ENTRY NAME="ProductSearch" KEY="ProductName"> 9.     <ACTION TYPE="ACCEPT" TASK="GO" DEST="ProductSearch.jsp?Product=$ProductName"> 10.    Enter Product Name: 11.  </ENTRY> 12.  <ENTRY NAME="SKUSearch" KEY="SKU"> 13.    <ACTION TYPE="ACCEPT" TASK="GO" DEST="SKUSearch.jsp?SKU=$SKU"> 14.    Enter SKU: 15.  </ENTRY> 16.</HDML> 

The first elements to point out are the mandatory opening <HDML> and closing </HDML> tags in lines 1 and 16. Notice that this is similar to how HTML code is written, with the exception of the required version number, in this case version 3.0. Inside these tags, the HDML code is broken down into decks and cards. Each segment of code that is downloaded is a deck; hence, the entire set of code displayed in Listing 13.1 is one deck. Within each deck, you can have one or more cards. In this example, three cards are shown. The first starts on line 2, with the <CHOICE> tag, the second and third start on line 8 and 12, respectively, with the <ENTRY> tags. Each card acts as a single page that can be displayed on the wireless device. Within the HDML code, you have the option of moving to another card within the current deck, or to download another deck and link to it.

In this example, you can see both types of references in between the <CHOICE> </CHOICE> tags. These tags provide the user with a selection of choices. This is the preferred way to obtain input from a user. It is much more effective than having the user enter data using the keypad, which is cumbersome and slow. The choice card lets the user select any of the choices presented, and will then move the user to the destination specified by the DEST attribute. If, for example, the user selects Search by Name or Search by SKU on lines 4 or 5, he or she will be directed to the other cards within this deck. For example, selecting the Search by Name will move the user to the card starting on line 8, which has the matching NAME="ProductSearch". However, if the user selects the Inventory List choice on line 6, he or she will download the HDML code that is generated by inventorylist.jsp Java ServerPage.

If you look at the second card starting on line 8, you can see that we are obtaining user input in another way, via the <ENTRY> tag. In this case, the user will input the product name, then pass this value to the ProductSearch.jsp page, as shown on line 9. The third card works in a similar manner, except the SKU is entered and the value is passed to the SKUSearch.jsp page. In this way, you can create HDML applications that retrieve dynamic content based on the values entered by the application user.

One last item to note in this listing is that because HDML is not based on XML, quotes are not required around the attribute values. Notice that the destination specified by the DEST attribute in line 5 has quotes around it, while the DEST in line 6 does not. Both of these are valid for HDML applications. That said, it is a good idea to use quotes, since they are required in the other more common wireless markup languages such as WML and XHTML.

HELPFUL RESOURCE 

For more information on creating HDML applications, the HDML style guide provided by Openwave is a great resource. It can be downloaded from http://demo.openwave.com/pdf/styleguides/hdml_style.pdf.

WML

The Wireless Markup Language (WML) is a part of the Wireless Application Environment (WAE) as defined in the Wireless Application Protocol (WAP). Unlike HDML, WML is based on XML, making the syntax requirements somewhat stricter. For example, if a tag is not closed, the WML deck will not work—plain and simple. This is just one case; there are many other differences between WML and HDML (and HTML, for that matter) that warrant mentioning. They will be discussed later in this section after we take a look at some basic aspects of WML.

WML is a successor to HDML, developed by Openwave, Nokia, Motorola, and others as represented by the WAP Forum (now the Open Mobile Alliance). It is targeted directly at mobile information devices such as cellular phones, PDAs, two-way pagers, and smart phones. Since these devices do not typically have large displays or support for advanced graphics and layouts, the markup language has to be lightweight and designed for the unique requirements of wireless connectivity. This is where WML fits into the picture. Because it was developed by a consortium of companies, all of which have a vested interest in the success of wireless Internet applications, WML has garnered tremendous support throughout the wireless industry. It is in widescale deployment throughout Europe, North America, South America, and parts of Asia. Most of the handsets being shipped in these regions support WAP and include WML browsers. The most common versions of WML are 1.1 and 1.2.1, although WML2 is gaining momentum.

In general, when creating Internet applications for wireless phones, WML is the markup language of choice. This may change with the release of WAP 2.0, which uses XHTML as the markup language, although its widespread adoption is still some time off. Just as HDML is still commonly used in North America even several years after the arrival of WAP, WML will continue to be used for many years to come as device manufacturers slowly move to XHTML. Fortunately, both WML and XHTML are XML-based, making the transition between the two straightforward. Actually, today, many companies are developing their applications in XHTML, and use conversion tools and transcoding technology to translate the XHTML into other markup languages such as WML. Taking this approach makes future markup language transitions much more manageable.

For many Web developers, the move to WML can be bittersweet, simply because many of the screens are 12 characters wide and 5 lines high; if you are used to creating sophisticated Web pages, with much of the emphasis on presentation and graphics, WML applications present a significant change. In most cases, wireless Web applications are focused on accessing data, with a specific task in mind. They are not geared at generic Web surfing. For example, if you want to check the inventory level of a particular product, a wireless Internet application would work quite well. You could simply do a search based on a product name or, better yet, an SKU, and receive the response you are looking for. It would not, however, be effective as a product catalog, where many details and, often, images are required. The focus of successful WML applications is on making sure that, one, all of the relevant data is there, and, two, that the navigation to that data is not too cumbersome.

Another major difference between desktop Web development and wireless development are the browsers. For wireless applications, the microbrowsers are quite simple. Unlike the immensely complex desktop browsers, such as Internet Explorer and Netscape, the wireless microbrowsers are often limited to very simplistic commands such as Submit, Back, Link, and More. Interaction with the browser is accomplished using soft keys, which can be programmed within your WML code. (You can find more information on wireless Internet technology, including microbrowsers, in Chapter 14, "Wireless Internet Technology and Vendors.")

WML Example

The best way to learn more about WML programming is by looking at an example. Listing 13.2 shows WML code that could be used for the first screen of an inventory search application. Figure 13.2 shows how this code would look in the Openwave WAP emulator.

Figure 13.2: Openwave WML Emulator showing output from sample code in Listing 13.2.

Listing 13.2: WML code for inventory sample.

 1.  <?xml version="1.0" encoding="UTF-8"?> 2.  <!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN" "http://www.wapforum.org/DTD/wml_1.1.xml"> 3.  <wml> 4.    <card > 5.      <p align="center"><i>Inventory Search</i></p> 6.      <p align="left"> 7.      <select> 8.        <option>Search by Name 9.          <onevent type="onpick"> 10.           <go href="#ProductSearch"></go> 11.         </onevent> 12.       </option> 13.       <option>Search by SKU 14.         <onevent type="onpick"> 15.           <go href="#SKUSearch"></go> 16.         </onevent> 17.       </option> 18.       <option>View Inventory List 19.         <onevent type="onpick"> 20.           <go href="Inventorylist.wml"></go> 21.         </onevent> 22.       </option> 23.     </select> 24.     </p> 25.   </card> 26.   <card > 27.   <!--WML code here for Product Search--> 28.     <p> 29.       Enter Product Name: 30.       <input name="product" emptyok="false"></input> 31.     </p> 32.   </card> 33.   <card > 34.   <!--WML code here for SKU Search--> 35.     <p> 36.       Enter SKU: 37.       <input name="sku" emptyok="false"></input> 38.     </p> 39.   </card> 40. </wml> 

If you are familiar with XML, and have done some Web page development, then programming WML applications will not be difficult. Similar to HTML and HDML pages, all of the content is contained within opening and closing tags, in this case <wml> and </wml>. The only exceptions are two lines at the beginning that are there present for XML compliance:

• The first line of every XML document is <?xml version="1.0">.

• The second line is the Document Type Definition (DTD) to which it conforms. In this case, we are using the WapForum DTD for WML 1.1. This is not a requirement for all XML documents.

Since WML is XML-based, it has to adhere to the rules of XML. The following are some of the major differences that you will notice in WML versus HDML and other non-XML-based languages:

• All WML elements must be closed.

• WML elements must be properly nested.

• WML documents must be well-formed.

• WML tag names must be lowercase.

These rules may seem quite strict at first, especially if you have been doing a lot of HTML development. Do not worry; after developing an application or two, you will get used to it, which is important because other XML-based languages such as XHTML are becoming increasingly popular. We will take a closer look at XHTML later in this chapter. Now we will continue to investigate the WML code shown in Listing 13.2.

WML is divided into decks and cards, similar to HDML. This example contains one deck containing three cards. Each WML deck contains at least one card and has a maximum size of 1492 bytes (note, however, that smaller decks, ideally under 800 bytes, download quicker and are more manageable by the device's memory cache). The cards in this example start on lines 4, 26, and 33. Each card will be displayed on the phone individually, equivalent to an HTML page for desktop browsers. Figure 13.2 shows the contents of the first card, lines 4–25 on an Openwave emulator.

Line 5 demonstrates the use of tags, in this case, the paragraph tag, <p>, as well as an attribute with a value, align="center". All text within a card should be enclosed within <p> </p> tags; and, remember, they have to be closed, and cannot be nested. If you want to add a line break, you can use the familiar <br> tag. Similar to the other WML tags, it has to be closed using either <br/> or <br></br>. Also of interest are the quotes around the attribute value. All WML attribute values have to be enclosed in double quotes.

As we move to the more functional areas of the example, we have the <select> tag in line 7. This presents the user with the options specified inside it. In our example we have three options:

• Search by Name.

• Search by SKU.

• View Inventory List.

This is a better technique for user input than requiring them to type on the device's keypad. Within the <select> tag, the <option> tag denotes each option.

WML has several options for moving between cards and decks. The example uses the <onevent> tag in conjunction with a <go> tag. When an item is selected, the user is moved to the URL argument specified in the <go> tag. In the example, lines 10 and 15 will take the user to other cards within the same deck, in this case to cards with and , respectively. The link on line 20 is different in that it links to another deck, which will then be downloaded and displayed. If you need to send information back to the server, this can be accomplished by using the <postfield> element within the <go> tag. Other linking methods can also be used in WML. Some common tags are <do> and other syntaxes of the <option> tag, such as using the onpick attribute:

 <option onpick="#ProductSearch">Search by Name</option> 

Most applications are not considered complete unless they enable user input. In WML, this is accomplished using the <input> tag. In lines 30 and 37, the user can enter input and have it stored in the related variable. For the Product Name input, we store the value entered into the product variable as specified in the name="product" attribute. There is also an option to set the type attribute to either "text" or "password", depending on whether the text should be displayed or concealed with asterisks. If you want to have default text displayed, possibly to reduce the amount of user input required, you could set the value attribute.

HELPFUL RESOURCE 

For more information on creating WML applications, the WML style guide provided by Openwave is a great resource. It can be downloaded from http://demo.openwave.com/pdf/styleguides/wml_style.pdf.

WMLScript

WMLScript provides a way to add more advanced capabilities to WML applications. Just as JavaScript of VBScript may be used in conjunction with HTML, WMLScript is used with WML to provide client-side logic. This is an important concept, because each request to the server can add a significant amount of wait time for the user. The following are some of the most common uses of WMLScript for WAP applications:

• Validation of user input

• Access device facilities, such as adding numbers to an address book

• Creation of dialogs and messages, avoiding round-trips to the server

If you want to use WMLScript in your applications, you will create the script in files with the extension .wmls. Rather than including the WMLScript in the WML file, as JavaScript would be in an HTML file, WMLScript is contained in a separate file and invoked from the WML card just as any other URL. The following is an example:

 <a href="validateuser.wmls#foo($(user))>Validate User</a> 

You will also have to ensure that both your microbrowser and the WAP gateway have WMLScript support. In addition, you may have to register the MIME types with your HTTP server.

Within your WMLScript pages, you can create both For and While loops; create functions, and libraries of functions; display dialog boxes; and have advanced interaction with the microbrowser.

Note 

It is beyond the scope of this book to go into depth about WMLScript's capabilities, so if you are interested in learning more about WMLScript, visit http://demo.openwave.com/pdf/50/wmls_dev_guide.pdf to view the Openwave WMLScript Developer's Guide.

HTML

Most developers have some experience with HTML; and if they do not, an abundance of material is available on the subject. For these reasons, this section is brief, its purpose only to provide some background information and details regarding the flavors of HTML that are being used for wireless applications.

HTML is the de facto language of the World Wide Web. Web developers worldwide use various versions of HTML to create rich, sophisticated Web sites, primarily viewed with either Internet Explorer or Netscape browsers. Over time, the complexity of HTML has increased dramatically. In 1995, HTML version 2.0 was defined. At that time, Web sites primarily displayed static data only, providing a means for companies to display brochures and similar content, and for individuals to display various types of personal information. Before long, more complex (and interesting) sites started appearing online, many of them based on HTML 3.2, which was released in 1997. It was around this time that we started seeing dynamic content, often generated using Common Gateway Interface (CGI) executables. Soon afterward, HTML 4.0 was introduced, adding a new level of functionality to Web development. Interactive, transaction-based, Web applications are now the norm. It is not unusual to perform bank transactions, make purchases, or book entire vacations online. In many cases, this is the preferred way to interact with many institutions.

In order to support these advanced applications, server-side technology had to evolve dramatically. Businesses now have several options for creating dynamic content, including Java servlets and JavaServer Pages (JSPs), Active Server Pages (ASPs), as well ISAPI, NSAPI, and CGI executables. Some of these technologies are discussed later in this chapter in the section called Content-Generation Technologies.

Not to be left behind, the Web browsers had to evolve as well. Netscape and Internet Explorer continued to have new features, making it easier for developers to create Web applications. As the applications evolved, some of the rules of the language were relaxed, to the point where even poorly written HTML code displayed without errors. Developers started noticing that they could get away with these "shortcuts," and HTML code became increasingly sloppy. Today it is estimated that close to 95 percent of HTML pages are not programmed according to the specification. The most common offenses are unclosed tags and incorrect nesting of elements.

Enter wireless Internet applications. It only made sense that the language of the wireless Internet would be the same as the language of the World Wide Web. This introduced a problem, however. HTML was much too complex, requiring too much processing power for parsing, to be suitable for wireless devices. The solution was to introduce subsets of HTML that could be used for wireless devices. These subsets include Compact HTML, and Web Clippings. Both of these languages are subsets of HTML, with the more complex aspects of the specification removed.

The HTML syntax supported by wireless devices often resembles HTML versions 2.0 and 3.2. In Listing 13.3 is an example of HTML code that can be used for wireless Internet applications. Many of the HTML browsers for the Palm OS, Pocket PC, and Symbian OS have support for a decent subset of HTML 3.2, on which this sample is based.

Listing 13.3: HTML code for inventory sample.

 1.  <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> 2.  <html> 3.  <head> 4.    <title>Inventory List</title> 5.  </head> 6.  <body> 7.  <P align=left><FONT size=4><STRONG>Inventory Product List</STRONG></FONT> 8.  <br> 9.  <br> 10.  <TABLE cellPadding=3 border=1> 11.    <TR> 12.      <TD><STRONG>Product </STRONG></TD> 13.      <TD><STRONG>Quantity</STRONG></TD> 14.      <TD><STRONG>Price($)</STRONG></TD> 15.    </TR> 16.    <TR> 17.      <TD>Sony TRV30 18.      <TD>17 19.      <TD>1699.99 20.    </TR> 21.    <TR> 22.      <TD>Hitachi VMD875L 23.      <TD>24 24.      <TD>599.99 25.    </TR> 26.    <TR> 27.      <TD>Sony DCR-IP7BT 28.      <TD>11 29.      <TD>2199.99 30.    </TR> 31.    <TR> 32.      <TD>JVC GR-DV2000 33.      <TD>4 34.      <TD>1599.99 35.    </TR> 36.  </TABLE> 37. </BODY> 38. </HTML> 

One of the downsides of basing the wireless markup language on HTML is that you inherit much of the sloppy programming that goes with it. Look at the example in Listing 13.3 to see the common tags found in HTML documents, such as the opening <html>, <head>, and <body> tags in lines 2, 3, and 6, respectively. In line 7, is the first occurrence of a missing closing tag. The paragraph tag, <p>, is not closed with a corresponding </p> tag. This type of omission is common in HTML programming, and generally does not cause any errors in the browser. Move down the code and you will see similar omissions in the table entries. The <TD> tags for each product entry do not have a closing </TD> tag in lines 17–20, 22–24, 27–29, and 32–34. In addition, you can also see that the tags are not case-sensitive. For example, the opening <body> tag in line 6 is lowercase, while its corresponding closing </BODY> tag in line 37 is all uppercase. Again, this does not create an error in HTML browsers.

The output of the code in Listing 13.3 is shown on the Pocket Internet Explorer browser on the Pocket PC emulator in Figure 13.3. This browser supports most of the HTML 3.2 specification, omitting only very advanced features.

Figure 13.3: Mobile Internet Explorer showing output from sample HTML code in Listing 13.3.

cHTML

The most popular subset of HTML is Compact HTML, or cHTML. Its popularity is based largely on the fact that cHTML is the markup language used by the phenomenally successful i-Mode service produced by NTT DoCoMo in Japan. i-Mode is fundamentally a product offering that allows users to access Internet content from wireless devices. It is really a wireless Internet brand, similar to AOL on the wired Internet. This type of approach has worked extremely well for NTT DoCoMo. Within the first year of its introduction, NTT DoCoMo had close to 10 million subscribers for the i-Mode service. That number easily surpassed the number of wireless Internet users in North America and Europe combined. While i-Mode is not the only factor contributing to the success of the wireless Internet in Japan, it definitely is a major contributor.

cHTML was submitted as a Note to the W3C in 1998, and is available for discussion purposes only. The W3C has not endorsed cHTML nor made any contribution to the language in any way. The original specification for cHTML from 1998 has remained unchanged, much as the specification for HDML. In many ways, the role of these two languages is similar, as cHTML is also a transition technology. Just as HDML has slowly moved aside for WML, cHTML is being replaced by XHTML in the i-Mode service. This is a very welcome move, allowing XHTML to become the language of the wireless Internet, in use by the two most prevalent offerings, WAP 2.x and i-Mode.

Like others in this category, the goal of cHTML is to create a markup language that is suitable for small information devices such as smart phones, communicators, and PDAs. Interestingly, cHTML is based on all three HTML specifications—2.0, 3.2, and 4.0—so it can take advantage of the HTML-based content resources, software tools, and documents. It has taken aspects from each of these HTML versions to create a complete language for limited-resource devices. The creators of cHTML have taken the following requirements into account:

• Hardware restrictions of the devices, including limited memory, low power central processing unit (CPU), and small displays.

• The navigation restrictions of the device: Moving between sets of information has to be possible with a minimum number of operations.

• Wireless network agnostic: The markup language does not depend on the underlying wireless protocol being used.

The design of cHTML is based on four main principles:

• It is completely based on current HTML W3C recommendations.

• It is a light specification, allowing it to run on mobile devices.

• It can be viewed on a mono-screen display.

• It is easy for users to operate.

In order to accomplish the goals of the language, certain features of HTML have to be excluded. Some of these include the following:

• Support for frames and tables

• JPEG image support

• Image maps

• Multiple-character fonts and styles

• Background color and images

• Stylesheets

Though it benefits by being based on HTML, cHTML also loses by not being based on XML. You will, for instance, see the same sloppy programming in cHTML that is commonly found in HTML. Fortunately, the move to XHTML provides us with a language that is based on both HTML and XML.

HELPFUL RESOURCE 

If you are interested in seeing the complete cHTML Note submitted to the W3C, which contains a complete list of the tags supported by cHTML, visit www.w3.org/TR/1998/NOTE-compactHTML-19980209.

XHTML

This brings us to the eXtensible HyperText Markup Language, or XHTML, an XML-compliant version of HTML. To reiterate, XHTML is the direction in which wireless markup languages are moving. The convergence of markup languages on XHTML is expected to increase the rate of development for m-commerce and m-business applications. Companies building wireless Internet applications can now focus on one markup language, so they can concentrate their efforts on the applications they are building, rather than on the technical challenge of developing with multiple markup languages simultaneously.

XHTML 1.0 became an official W3C recommendation in early 2000, making it a Web standard. It is almost identical to HTML 4.0.1, with a few rules added for XML compliancy.

Note 

For the same reasons that HTML was not examined in depth, this section on XHTML will be kept brief, focusing only on the areas where XHTML differs from HTML, and on the profiles being used for wireless development, namely XHTML Mobile Profile (XHTML-MP) and XHTML Basic. In the not-too-distant future, comparing HTML and XHTML will no longer be required as XHTML is intended to be a replacement for HTML. Most of the new desktop Web browsers will support XHTML natively, resulting in a higher level of compatibility among browsers.

Why XHTML?

As noted earlier, desktop Web browsers allow for very poorly formatted HTML Web pages, making it difficult to have cross-platform, or even cross-browser, compatibility. Though much of the HTML code on the Web does not follow the rules of HTML, it will execute problem-free on a desktop browser. But browsers in other locations, such as on PDAs, mobile phones, and intelligent appliances, do not have enough computing power to compensate for poor programming. This is where XML comes into play.

XML requires all code to be programmed correctly, making the job of the interpreter or, in this case, the browser, much easier. XML itself is a way to describe data, whereas HTML is a way to present data. When we bring these two languages together, the result is a markup language that can be used now and that is adaptable to future change.

How XHTML Differs from HTML

Knowing the differences between XHTML and HTML will help you to start creating better HTML code now, so fewer changes will be required later when the browsers and other software programs start to require XHTML. The following are the most important differences:

• XHTML documents must be well formed. Because XHTML is XML-based, documents must conform to XML syntax rules.

• XHTML elements must be properly nested.

• Tags and attributes must be lowercase.

• All XHTML elements must be closed. You can use a closing slash with any empty element such as <br/> or <a />.

• All attribute values must be enclosed in quotation marks.

• A DOCTYPE declaration is required.

Let's look at an example to demonstrate some of these differences. Listing 13.4 contains the XHTML version of the HTML code shown earlier in Listing 13.3. Note that the changes made in converting the document from HTML to XHTML do not affect how it appears in a browser; that is, the code shown in Listing 13.4 will display as the HTML code did, shown previously in Figure 13.3.

Listing 13.4: XHTML code for inventory sample.

 1.  <?xml version="1.0"?> 2.  <!DOCTYPE html PUBLIC "-//OPENWAVE//DTD XHTML Mobile 1.0//EN" "http://www.openwave.com/dtd/xhtml-mobile10.dtd"> 3.  <html xmlns="http://www.w3.org/1999/xhtml"xml:lang="en"> 4.  <head> 5.    <title>Inventory List</title> 6.  </head> 7.  <body> 8.  <p align="left"><font size="4"><strong>Inventory Product List</strong></font></p> 9.  <br/> 10. <br/> 11. <table cellPadding="3" border="1"> 12.   <tr> 13.     <th>Product</th> 14.     <th>Quantity</th> 15.     <th>Price($)</th> 16.   </tr> 17.   <tr> 18.     <td>Sony TRV30</td> 19.     <td>17</td> 20.     <td>1699.99</td> 21.   </tr> 22.   <tr> 23.     <td>Hitachi VMD875L</td> 24.     <td>24</td> 25.     <td>599.99</td> 26.   </tr> 27.   <tr> 28.     <td>Sony DCR-IP7BT</td> 29.     <td>11</td> 30.     <td>2199.99</td> 31.   </tr> 32.   <tr> 33.     <td>JVC GR-DV2000</td> 34.     <td>4</td> 35.     <td>1599.99</td> 36.   </tr> 37. </table> 38. </body> 39. </html> 

We start to see the differences between the HTML and XHTML documents immediately. On line 1 we have the <?xml version="1.0"?> declaration, as required by all XML documents. On line 2 we have the required DOCTYPE declaration, in this case using the XHTML Mobile Profile. Notice that the <DOCTYPE> does not have a closing element. This is because it is not part of the XHTML document itself, and therefore does not require a closing tag. This declaration tells the browser which XHTML document type the document conforms to.

In addition to these differences, we also can see that this document is well formed: All the tags are in lowercase and are properly closed. For example, all of the table cells <td> have closing tags </td>, which were not present in the HTML document in Listing 13.3.Also, the attribute values are enclosed in quotation marks, as seen in lines 8 and 11.

In our simple example, the required changes were quite straightforward. Even so, the HTML document did require a significant number of changes to be proper XHTML. For developers who manage hundreds, or possibly thousands, of HTML pages, updating them all to XHTML can be a daunting proposition. If you find yourself in this position, you may want to look into the HTML Tidy or JTidy tools, which will do the HTML-to-XHTML conversion for you. (More information on these tools can be found at the Source Forge Web site at http://tidy.sourceforge.net.)

XHTML Basic and XHTML-MP

The markup language for the WAP Application Environment 2.0 (WAE) is XHTML Mobile Profile (XHTML-MP). This profile is a superset of XHTML Basic, as defined by the W3C. By taking advantage of XHTML modularization, XHTML-MP is very extensible, permitting the addition of new elements as required. In addition, documents based on the Basic profile of XHTML will be completely operable in XHTML-MP browsers.

XHTML Basic defines a document type that is rich enough for advanced content authoring yet can be used across a variety of clients, including desktops, PDAs, TV, and mobile phones. It is the mobile version of XHTML 1.0, supporting everything except features such as frames that are not appropriate for devices with small screens.

Similar to cHTML, XHTML Basic will be able to take advantage of the large number of HTML software programs and resources available. This means that developers will be able to test their applications in a desktop browser and have confidence that the layout will be an accurate representation of the browser on the mobile device. In addition, the information on XHTML given earlier in this chapter also applies to XHTML Basic.

Other than being XML-based, the other major difference between XHTML Basic and cHTML is XHTML Basic's support for cascading style sheets (CSS). CSS are executed on the browser, describing the screen presentation of documents without sacrificing device independence or requiring the addition of new markup language tags. Using CSS, an application developer can specify the presentation of the Web application in one place. If changes are required, they can be made to the style sheet and will be automatically reflected in all pages on the site. Residing on the client, CSS also help to alleviate the overhead on the server, where transcoding techniques are often used to transform documents to different markup languages. (Information on transcoding can be found in the Thin Client Application Models section of Chapter 12, "Thin Client Development.")

With support from both the Open Mobile Alliance and W3C, XHTML Basic is assured to have widespread acceptance now and in the future. (More information on XHTML Basic can be found on the W3C Web site at www.w3.org/TR/xhtml-basic. You can also download the full XHTML Mobile Profile reference from Openwave at http://developer.openwave.com.)

VoiceXML

One other markup language warrants mentioning in this chapter: the Voice eXtensible Markup Language (VoiceXML). VoiceXML is an XML-based markup language that allows access to Web applications and content via a telephone rather than a Web browser. Just as a Web browser interprets markup languages such as WML or XHTML, a voice browser interprets VoiceXML, then uses Text-to-Speech (TTS) to relay the information to the user.

VoiceXML was developed by the VoiceXML Forum, which was founded by AT&T, Lucent, Motorola, and IBM. In addition to the founding members, the VoiceXML Forum has an additional 400 members that support the growth of VoiceXML for voice-based applications. The future looks promising for VoiceXML. In 2000, VoiceXML 1.0 was accepted by the W3C as the basis for developing a dialog-based markup language. In 2002, VoiceXML 2.0 became an official W3C recommendation.

If you are interested in creating voice-based applications, you will want to read Chapter 15, "Voice Applications with VoiceXML," which is dedicated to the VoiceXML markup language and related VoiceXML technologies.