Visit https://ebooknice.

com to download the full version and

explore more ebooks

(Ebook) Getting started with WAP and WML by Huw

Evans, Paul Ashworth ISBN 9780782128703, 078212870X

_____ Click the link below to download _____

https://ebooknice.com/product/getting-started-with-wap-
and-wml-1217136

Explore and download more ebooks at ebooknice.com

Here are some recommended products that might interest you.
You can download now and explore!

(Ebook) Biota Grow 2C gather 2C cook by Loucas, Jason; Viles, James

ISBN 9781459699816, 9781743365571, 9781925268492, 1459699815,
1743365578, 1925268497

https://ebooknice.com/product/biota-grow-2c-gather-2c-cook-6661374

ebooknice.com

(Ebook) SAT II Success MATH 1C and 2C 2002 (Peterson's SAT II Success)

by Peterson's ISBN 9780768906677, 0768906679

https://ebooknice.com/product/sat-ii-success-
math-1c-and-2c-2002-peterson-s-sat-ii-success-1722018

ebooknice.com

(Ebook) Matematik 5000+ Kurs 2c Lärobok by Lena Alfredsson, Hans

Heikne, Sanna Bodemyr ISBN 9789127456600, 9127456609

https://ebooknice.com/product/matematik-5000-kurs-2c-larobok-23848312

ebooknice.com

(Ebook) Getting StartED with Google Apps by Paul Darbyshire, Adam

Darbyshire ISBN 9781430226659, 143022665X

https://ebooknice.com/product/getting-started-with-google-apps-1538190

ebooknice.com
(Ebook) 25 Recipes for Getting Started with R by Paul Teetor ISBN
9781449303235, 1449303234

https://ebooknice.com/product/25-recipes-for-getting-started-
with-r-1565116

ebooknice.com

(Ebook) Getting StartED with Google Apps by Paul Darbyshire, Adam

Darbyshire (auth.) ISBN 9781430226659, 9781430226666, 143022665X,
1430226668

https://ebooknice.com/product/getting-started-with-google-apps-4180354

ebooknice.com

(Ebook) Getting Started With Angular by Stephen Adams

https://ebooknice.com/product/getting-started-with-angular-22526942

ebooknice.com

(Ebook) Getting Started with Python and Raspberry Pi by Dan Nixon

https://ebooknice.com/product/getting-started-with-python-and-
raspberry-pi-54981210

ebooknice.com

(Ebook) Getting Started with z_OS Data Set Encryption by kan

https://ebooknice.com/product/getting-started-with-z-os-data-set-
encryption-50195594

ebooknice.com
Getting Started with WAP and WML
Huw Evans
Paul Ashworth

Associate Publisher: Richard Mills

Contracts and Licensing Manager: Kristine O'Callaghan
Acquisitions Editor: Brenda Frink
Developmental Editor: Tracy Brown
Editors: Ronn Jost, Julie Sakaue
Production Editor: Kylie Johnston
Contributing Technical Reviewer: Steve Potts
Lead Technical Editor: Steve Potts
Technical Editors: Steve Cook, Shayne Micchia
Book Designer: Kris Warrenburg
Graphic Illustrator: Tony Jonick
Electronic Publishing Specialist: Judy Fung
Proofreaders: Laurie O'Connell, Laura A. Ryan
Indexer: Nancy Guenther
CD Technician: Keith McNeil
CD Coordinators: Kara Schwartz, Erica Yee
Cover Designer: Design Site
Cover Illustrator: Jack D. Myers, Design Site
Copyright © 2001 SYBEX Inc., 1151 Marina Village Parkway, Alameda, CA 94501. World rights
reserved. The authors created reusable code in this publication expressly for reuse by readers.
Sybex grants readers permission to reuse for any purpose the code found in this publication or its
accompanying CD-ROM so long as authors are attributed in any application containing the
reusable code and the code itself is never distri-buted, posted online by electronic transmission,
sold, or commercially exploited as a stand-alone product. Aside from this specific exception
concerning reusable code, no part of this publication may be stored in a retrieval system,
transmitted, or reproduced in any way, including but not limited to photocopy, photograph,
magnetic, or other record, without the prior agreement and written permission of the publisher.
Library of Congress Card Number: 2001087088
ISBN: 0-7821-2870-X
SYBEX and the SYBEX logo are trademarks of SYBEX Inc. in the USA and other countries.
The CD interface was created using Macromedia Director, COPYRIGHT 1994, 1997–1999
Macromedia Inc. For more information on Macromedia and Macromedia Director, visit
http://www.macromedia.com.

TRADEMARKS: SYBEX has attempted throughout this book to distinguish proprietary

trademarks from descriptive terms by following the capitalization style used by the manufacturer.
The author and publisher have made their best efforts to prepare this book, and the content is
based upon final release software whenever possible. Portions of the manuscript may be based
upon pre-release versions supplied by software manufacturer(s). The author and the publisher
make no representation or warranties of any kind with regard to the completeness or accuracy of
the contents herein and accept no liability of any kind including but not limited to performance,
merchantability, fitness for any particular purpose, or any losses or damages of any kind caused
or alleged to be caused directly or indirectly from this book.
Manufactured in the United States of America
10 9 8 7 6 5 4 3 2 1
Terms and Conditions
The media and/or any online materials accompanying this book that are available now or in the
future contain programs and/or text files (the "Software") to be used in connection with the book.
SYBEX hereby grants to you a license to use the Software, subject to the terms that follow. Your
purchase, acceptance, or use of the Software will constitute your acceptance of such terms.
The Software compilation is the property of SYBEX unless otherwise indicated and is protected
by copyright to SYBEX or other copyright owner(s) as indicated in the media files (the
"Owner(s)"). You are hereby granted a single-user license to use the Software for your personal,
noncommercial use only. You may not reproduce, sell, distribute, publish, circulate, or
commercially exploit the Software, or any portion thereof, without the written consent of SYBEX
and the specific copyright owner(s) of any component software included on this media.
In the event that the Software or components include specific license requirements or end-user
agreements, statements of condition, disclaimers, limitations or warranties ("End-User License"),
those End-User Licenses supersede the terms and conditions herein as to that particular
Software component. Your purchase, acceptance, or use of the Software will constitute your
acceptance of such End-User Licenses.
By purchase, use or acceptance of the Software you further agree to comply with all export laws
and regulations of the United States as such laws and regulations may exist from time to time.
Reusable Code in This Book
The authors created reusable code in this publication expressly for reuse for readers. Sybex
grants readers permission to reuse for any purpose the code found in this publication or its
accompanying CD-ROM so long as all authors are attributed in any application containing the
reusable code, and the code itself is never sold or commercially exploited as a stand-alone
product.
Software Support
Components of the supplemental Software and any offers associated with them may be
supported by the specific Owner(s) of that material but they are not supported by SYBEX.
Information regarding any available support may be obtained from the Owner(s) using the
information provided in the appropriate read.me files or listed elsewhere on the media.
Should the manufacturer(s) or other Owner(s) cease to offer support or decline to honor any offer,
SYBEX bears no responsibility. This notice concerning support for the Software is provided for
your information only. SYBEX is not the agent or principal of the Owner(s), and SYBEX is in no
way responsible for providing any support for the Software, nor is it liable or responsible for any
support provided, or not provided, by the Owner(s).
Warranty
SYBEX warrants the enclosed media to be free of physical defects for a period of ninety (90)
days after purchase. The Software is not available from SYBEX in any other form or media than
that enclosed herein or posted to www.sybex.com. If you discover a defect in the media during
this warranty period, you may obtain a replacement of identical format at no charge by sending
the defective media, postage prepaid, with proof of purchase to:
SYBEX Inc.
Customer Service Department
1151 Marina Village Parkway
Alameda, CA 94501
(510) 523-8233
Fax: (510) 523-2373
e-mail: <[email protected]>

WEB: WWW.SYBEX.COM

After the 90-day period, you can obtain replacement media of identical format by sending us the
defective disk, proof of purchase, and a check or money order for $10, payable to SYBEX.
Disclaimer
SYBEX makes no warranty or representation, either expressed or implied, with respect to the
Software or its contents, quality, performance, merchantability, or fitness for a particular purpose.
In no event will SYBEX, its distributors, or dealers be liable to you or any other party for direct,
indirect, special, incidental, consequential, or other damages arising out of the use of or inability
to use the Software or its contents even if advised of the possibility of such damage. In the event
that the Software includes an online update feature, SYBEX further disclaims any obligation to
provide this feature for any specific duration other than the initial posting.
The exclusion of implied warranties is not permitted by some states. Therefore, the above
exclusion may not apply to you. This warranty provides you with specific legal rights; there may
be other rights that you may have that vary from state to state. The pricing of the book with the
Software by SYBEX reflects the allocation of risk and limitations on liability contained in this
agreement of Terms and Conditions.

Shareware Distribution
This Software may contain various programs that are distributed as shareware. Copyright laws
apply to both shareware and ordinary commercial software, and the copyright Owner(s) retains all
rights. If you try a shareware program and continue using it, you are expected to register it.
Individual programs differ on details of trial periods, registration, and payment. Please observe
the requirements stated in appropriate files.
Copy Protection
The Software in whole or in part may or may not be copy-protected or encrypted. However, in all
cases, reselling or redistributing these files without authorization is expressly forbidden except as
specifically provided for by the Owner(s) therein.
This book is dedicated to all those brave pioneers in the world of the wireless Internet, who like
ourselves can see the limitless opportunities created by enabling anyone to connect to a server
from wherever they are. We think it will have an even more profound effect on the way we live
and do business than the Internet has already had. By reading this book, you become a pioneer
in the world of the wireless Internet, too, and we invite you to learn about the main wireless
Internet-enabling technology—WAP—and find out just how easily our vision can be turned into
reality.
ACKNOWLEDGMENTS
Writing this book was one of the most difficult tasks we've both ever taken on in our lives. We
both come from a computer consultancy background, and figured that if we can learn and
assimilate new technologies, then use them to resolve our clients' problems, it would be relatively
easy to learn and assimilate a technology and write a book about it. Not at all! First, we wanted to
develop an example WAP application that we could use as an ongoing example throughout the
book, in an attempt to make the learning experience as close to real life as possible. This became
much more difficult than you would ever imagine, as the application developed from a few static
WML cards to a fully functional WAP service with WML cards being served up by Java servlets.
But what fun it was learning how to program using Java servlets, then having the satisfaction of
seeing our own WML pages being generated by a Web server!
We both also went through big personal changes while writing this book. My second son, Hugo,
was born in October 2000, roughly halfway through writing the book. This made the task twice as
hard as it would have been, as suddenly I was holding a colicky baby during the evenings,
instead of writing this book! At the same time, my co-author, Huw Evans, changed jobs and found
himself ramping up in a new role at the same time as writing this book!
And through all this, the team at Sybex did a fantastic job of guiding us through our first book.
Tracy Brown got us up and running, and Kylie Johnston did a great job of coordinating the
project, as well as keeping the schedule on track when we both started getting bogged down with
events in our personal lives. There were also complete editing and production teams involved in
the creation of this book, whose care and diligence will ensure this book meets Sybex's high
quality standards. Finally, just as we were running out of time, Steve Potts of Geoworks came in
and helped us immeasurably by completing the unfinished parts of the book, as well as tying the
loose ends together and generally making sure that the content of the book was coherent.
Thanks to Steve for his enthusiasm and technical contributions in the writing of this book. A big
thank you to you all.
—Paul Ashworth

Introduction
The Wireless Application Protocol (WAP) is a new technology linking the Internet to wireless
portable devices. It marks the dawning of the new age of wireless commerce, a means of
communicating and performing wireless transactions that will represent a major change in the
way we live and do business.
WAP bridges the gap between the Internet and the wireless world, offering the potential for an
unlimited range of value-added services to be delivered to users irrespective of the network or
device they're using. This convergence of the Internet and cellular telephony, two of the fastest
growing technologies of the last decade, will allow the transformation of information on the
Internet to a form that can be displayed on the restricted screen sizes associated with cellular
phones and other portable devices such as personal digital assistants (PDAs).
WAP is the essential link between the Internet viewed through a PC browser and the increasing
capabilities of cellular phones and other wireless devices. It provides a single, industry-standard
mechanism for wireless application interoperability called the Wireless Markup Language (WML),
developed from the earlier Handheld Devices Markup Language (HDML). WML provides a clear
way for application developers and content providers to create a range of services via WAP
browsers installed on the new generation of wireless devices. WML is supported by a scripting
language called WMLScript, which brings procedural logic to client services.
Wireless devices use WML and WMLScript to produce content, and they make optimum use of
small displays and are designed to allow one-handed navigation. This WAP content is scalable
from a two-line text display all the way up to the more sophisticated full-graphics-capability
screens on the next generation of smart wireless devices.

The Next Internet Explosion

The Internet has changed the way people perceive and use the power of the computer. It has led
to a revolution in the way we communicate and do business. And just as the revolution is
beginning to influence the lives of the mainstream populations of most developed countries, the
Internet is itself on the verge of an even more explosive revolution in the way we access it. Within
the next couple of years, our ability to access the power of the Internet through wireless devices
will start to become second nature as new WAP-enabled cellular phones and computing devices
start to become commonplace.
A wireless device's screen can display only a few characters, its bandwidth is extremely limited,
and entering text is awkward. However, the success of WAP-enabled cellular phones will be
driven by the facts that users will be able to access WAP applications wherever they are and built-
in billing mechanisms will allow service providers to automatically charge the device's owner for
accessing services.
At the moment, European countries are leading the way in the adoption of cellular telephony. The
huge increase in the use of WAP has been in Europe, where countries like Germany and Finland
are setting the trends for the U.S. and the rest of the world to follow.
This emerging market for wireless portable devices is being driven by the cash-rich
telecommunications vendors who see a future as rosy for wireless commerce as the recent past
(and present) has been for desktop-based e-commerce. Leading telecom trailblazers Nokia of
Finland, Ericsson of Sweden, and Motorola of the U.S. are ramping up for the anticipated wireless
Internet explosion and are now making handsets with WAP capabilities generally available.
By 2004, it is estimated that there will be more than one billion cellular phones in circulation and
around 700 million wireless commerce users. By this time, the number of wireless data users
worldwide will have grown rapidly from the 31.7 million estimated in 1999 to around 750 million. In
developed countries, the percentage of wireless subscribers using data will be above 70 percent,
with the highest (79 percent) in Japan. Some analysts predict that within three years, more
people will be accessing the Internet from mobile phones than from PCs. One of the main
reasons for this is that, unlike with computers, people keep mobiles with them at home, in the
office, and on the move.
The first devices now entering the marketplace are slow and restricted both in format and content,
but they point the way to the future. WAP personal digital assistants and cellular phones are now
able to browse the Internet and access sites and services specially designed for them using
WML.
WAP will provide business with a new channel for existing and future services that can be
reached by their customers day or night wherever they go. The uses of WAP-enabled portable
devices are not restricted to only content push services such as accessing the latest sports
results, news, and weather. Users will be able to access sites allowing them, for example, to
reserve seats at restaurants, theaters, and hotels, and to conduct transactions such as
purchasing financial services and buying concert tickets.
By late 1998, WAP 1.0 had been superficially tested but had generated enough results to
determine that it had a few flaws. Forum members declared an interest in developing
enhancements to the standards, to extend the penetration of WAP. The enhancements were of
such great consequence to the future of WAP's success that the Forum decided to discard WAP
1.0, and eliminate backwards compatibility in the attempt to create a workable and successful
solution. The next release was to be an important baseline.
WAP 1.1 was announced in May of 1999; and soon after, WAP-enabled terminals started to enter
the market. The WAP standard's goal is to enable all wireless devices equipped with a WAP
microbrowser to access live information resources and applications. Content and application
developers support palmtops, laptops, and standard and smart mobile phones. They also support
a range of input and output devices including touch screens and bitmapped displays. Since the
publication of WAP 1.1, the gap between current wireless data and the third generation networks
expected to roll out in 2003/2004 has started to be bridged.
WAP 1.2 was announced in December of 1999, with a maintenance release 1.2.1 (formally
known as WAP June 2000) increasing interoperability. WML is the markup language of WAP.
Because WAP 1.1 is an important baseline, and because of the prevalence of WML 1.1 (as
specified in WAP 1.1) devices in the marketplace, it is this version we will use throughout this
book. We will also make you aware of changes introduced in WML 1.2 (in WAP 1.2) and WML
1.3 (in WAP June 2000) by highlighting the relevant version differences.

Chapter 1: Introducing WAP and WML

This chapter introduces you to the Wireless Application Protocol (WAP) and the key markup
language you'll need to grasp to develop content for WAP-enabled wireless devices. This
language, called Wireless Markup Language (WML), is supplemented by its own scripting
language, called WMLScript, which will be introduced before a discussion on WAP architecture,
standards, devices, and what the future holds in this fast-moving technological environment.

What Is WAP?
Wireless Application Protocol (WAP) is a set of standards designed to extend Internet services to
mobile phones, pagers, and personal digital assistants (PDAs). The development of WAP is
coordinated by an industry-wide group of companies under the banner of the WAP Forum. The
WAP Forum was created to apply the best principles of Internet application development to the
wireless environment. See the sidebar later in this chapter for more on the WAP Forum.

WAP has become the de facto worldwide standard for the presentation and delivery of wireless
information and telephony services on mobile phones and other wireless devices. It is an open
protocol that provides the same development standards to all vendors irrespective of the
underlying network system. It is designed to work under the low bandwidth constraints of wireless
networks. These constraints are currently around 10Kbps compared with the standard 56Kbps on
home computers using domestic telephone lines with standard dial-up modems. As most wireless
computing devices have limited processing power and memory, and are designed with screen
displays and small multifunction keypads, WAP was developed with these limitations in mind.
WAP was created to address three main issues related to data communications across wireless
networks: low bandwidth, high latency, and connection availability.
Because WAP is an open protocol, a number of manufacturers are producing a wide range of
WAP-enabled devices. These manufacturers in turn are able to source from a large range of
WAP-specified components because the server technology is also open. This general openness
and adoption of common standards means that developers, manufacturers, and content providers
are able to adopt WAP with confidence and benefit from the economies of scale.
WAP uses a client/server architecture that employs an unsophisticated wireless-based
microbrowser and requires only limited resources and a WAP gateway to deliver content from the
server where it is stored. It is a standard independent of the air interface, the user interface, and
the underlying data bearer. Therefore, it is entirely interoperable. Because WAP is based on
existing Internet technologies, it leverages the massive investment in similar conventional Web
tools, applications, servers, and their developers while considering the restricted bandwidth,
processing power, and memory currently available on wireless portable devices.
Web content is available over existing wireless communication networks through a WAP
gateway. Figure 1.1 illustrates how an established WWW infrastructure, based on the Hypertext
Transfer Protocol (HTTP), uses a WAP gateway to interface with the wireless network by
translating HTTP requests into wireless device requests.

Figure 1.1: The WAP gateway

The 1997 WAP Forum specification is unique in that it is truly global and spans the numerous
airlink standards. WAP specifies guidelines for the implementation of microbrowsers and the
network-resident servers that connect portable wireless devices to the network infrastructure and
the Web. For the carriers, the creation of WAP means minimum risk and investment, new sources
of revenue, and a more attractive, comprehensive suite of value-added services. For users, it
provides easy access via WAP-enabled handheld devices to the Web and secure access to
corporate intranets. Manufacturers also benefit from the provision of a global, open, de facto
standard. They're provided with a complete new range of marketing opportunities and revenue
streams, while the content providers and developers are confronted with the huge untapped
market of wireless customers and the prospect of 100 million WAP-enabled devices by mid-2001.

What Is WML?
Wireless Markup Language (WML) is to WAP and its handheld devices what Hypertext Markup
Language (HTML) is to the Web and browsers such as Netscape and Internet Explorer. It
describes how content is presented to the wireless device, allowing you to display information,
present input options, and tell user agents (programs that interpret WML, WMLScript, and other
forms of code—typically a microbrowser in a mobile phone) how to respond once an option has
been selected using the keypad.
WML is a subset or an application of the eXtensible Markup Language (XML), and because WAP
uses a similar model as the Internet, it allows content developers to quickly become proficient
with this relatively simple tag-based language while allowing a clear development path. WML is
based on the World Wide Web Consortium (W3C) guidelines for wireless access and works
similarly to HTML to deliver Web text using simple markup tags.
WML's user interface is a WAP microbrowser optimized to map onto mobile wireless devices. A
WML document is called a deck, which is comparable to an HTML page. Unlike the flat structure
of HTML content, WML documents—or decks—are divided into separate units of user interaction.
Each unit is called a card, and WAP services are created by letting the user navigate between the
cards of one or more decks in much the same way hyperlinks are used within and between HTML
documents.
WAP gateways provide the interface between the network and Internet or intranet services. From
this gateway, WML content is accessed over the Internet using the standard HTTP mechanism.
WAP developers and content providers can get up to speed quickly with WML, as it follows the
same programming model as the Web development model. It is a tag-based language specified
as an XML document type, so all existing XML tools and some HTML development environments
can be used to develop WAP applications. As standard HTTP is used for communication between
gateway and servers, developers can use off-the-shelf Web servers to deploy their applications.
Standard tools such as ColdFusion and CGI scripting languages such as Perl, PHP, and ASP
generate content for dynamic WML applications.
The WML specification was developed by the WAP Forum and defines the syntax, variables, and
elements to be used in a valid WML file. The WML 1.1 Document Type Definition (DTD) is
available from www.wapforum.org/DTD/wml_1.1.xml, and all WML applications must
correspond to it. The microbrowser that all WAP-compliant wireless devices are loaded with is
able to handle all entities in the WML 1.1 DTD.
The WAP gateway translates wireless device requests into HTTP requests and then redirects the
Web server's HTTP responses to the device. WML files being sent to WAP-enabled handheld
devices are compressed into a binary format by the WAP gateway. It is possible to translate
HTML into WML using a number of available filter tools, but in practice, the differing user
interfaces employed between the desktop and wireless environments make specific WML-tailored
solutions the norm.
A WAP emulator is a program that implements a WAP microbrowser, but is designed to run on a
non-WAP device, such as a Windows PC. Emulators are often used by developers to speed up
the development process, as well as to reduce the costs of using WAP during testing each time a
change is made. They are also useful to see how a real WAP device will look, because many of
these emulators mimic the look and feel of real WAP devices. A list of available emulators is
provided in later chapters. When a WAP emulator is used, a WAP gateway is not required
because WML files are downloaded from a Web server or local file, and the emulator renders it in
the Emulator window. Figure 1.2 shows this process.
Figure 1.2: Displaying WAP content using a gateway and an emulator

Applications and services written in WML become available to all network devices that are WAP
compliant, delivering a write once, use anywhere tool. WML developers can map soft keys
(appropriated to physical keys on the WAP-enabled device by the manufacturer) for easy user
input and take advantage of features designed to maximize the effect of displaying text on a
limited screen. Low-resolution graphics known as WBMPs can be used, and as bandwidth
increases, so too will the resolution of the graphics supported by the WAP specification. As long
as a recipient device is WAP compliant, the size of the device's display is automatically
accounted for by the microbrowser and the use of standard HTTP header mechanisms to learn
about a device's capabilities. These header mechanisms allow the developer to customize
applications to take advantage of different device characteristics. This technique is known as
device sensing and is the same in principle as the HTML of many Web sites that detect which
Web browser and version you are running to provide an optimal display and to allow support for
browser-specific features.
While WML is good at things like event processing, input and output handling, and rendering, it
has no practical processing abilities. It is, therefore, supplemented by the WMLScript scripting
language.

What Is WMLScript?
In addition to WML, the WAP Forum provides a scripting language called WMLScript. WMLScript
is used alongside WML (or independently of it) to provide intelligence in the form of procedural
logic to client services. WMLScript is to WML what JavaScript is to HTML. In fact, WMLScript is
based on ECMAScript, a derivative of JavaScript, and has been designed to support the relatively
low bandwidth restrictions applicable to handheld wireless devices.
WMLScript enhances the capabilities of WML in a number of ways. With it, you can access user
agent facilities, check user input, generate local messages and dialogs, and execute user agent
software.
This functionality allows you to locally program things like error messages and alerts for faster
viewing, add to your wireless address book, and interrogate SIM cards.
WMLScript defines functions containing flow control logic constructs such as while, if, and
for, which can be called from the main body of the WML program. Even so, WMLScript still
lacks basic programming features such as arithmetic functions, string handling, and WML 1.1
program interfacing capabilities. It therefore has to rely on a set of standard libraries to access
functions relating to dialog presentation, floating point numbers, string conversion, and integer
handling.
WMLScript is compiled by a WAP gateway into binary form to reduce the code's size and
therefore minimize transfer time. It defines a byte-code representation and a byte-code interpreter
for optimal utilization of current low bandwidth channels and wireless device memory restrictions.
In brief, WMLScript uses the following syntax rules:
§ The smallest unit of execution in WMLScript is a statement, and each statement must
end with a semicolon (;).
§ WMLScript is case sensitive.
§ Comments can either be single-line (beginning with //) or multi-line (bracketed by /*
and */). This syntax is identical to that of both C++ and Java.
§ A literal character string is defined as any sequence of zero or more characters
enclosed within double ("") or single (') quotes.
§ Boolean literal values correspond to true and false.
§ New variables are declared using the var keyword (i.e., var x;).
§ WMLScript has no type checking done at compile-time or runtime, and no variable
types are explicitly declared. Internally, the following data types are supported:
§ Boolean
§ Integer
§ Floating point
§ String
§ Invalid
You do not need to specify the type of any variable because WMLScript automatically attempts to
convert between the different types as required. It is also worth noting that WMLScript is not
object-oriented, so it is not possible to create your own user-defined data types programmatically.
WMLScript allows a variety of operators that support value assignment operations, arithmetic
operations, logical operations, string operations, comparison operations, and array operations.
WMLScript operators and expressions are nearly identical to those of the JavaScript
programming language.
Although WMLScript does not support the creation of new objects via object-oriented
programming, the six libraries that are provided help in the handling of many common tasks. The
Lang library includes functions for data type manipulation, absolute value calculations, and
random number generation. The optional Float library includes sqrt(), round(), and pow()
functions but is supported only on those wireless devices with floating point capabilities. The
String library contains a set of functions for performing string operations. Some of the functions
included in this library are length(), charAt(), find(), replace(), and trim(). A URL
library is provided for handling both absolute URLs and relative URLs. Extraction functions let you
retrieve individual components from absolute and relative URLs, and include getPath(),
getReferer(), and getHost(). A WMLBrowser provides go(), prev(), next(),
getCurrentCard(), and refresh(), where WMLScript can access the associated WML
context. Finally, a Dialogs library provides a set of typical user-interface functions including
prompt(), confirm(), and alert().

The WAP Forum

The Wireless Application Protocol Forum was created in 1997 to provide a worldwide open
standard for the delivery of Internet-based services to wireless handheld devices. It was formed
by an alliance of partners made up of telephone manufacturers, Motorola, Ericsson, Nokia, and
Unwired Planet, a US software company that changed its name to Phone.com (which recently
merged with Software.com to become Openwave).

Before the formation of this group, the concerned players were all working independently to
address the issue of developing a schema to increase the capabilities of wireless telephony
platforms. Ericsson had begun work with a protocol called ITTP (Intelligent Terminal Transfer
Protocol) with the aim of making it easy to add services to wireless platforms. Nokia was working
on their Smart Messaging concept, and Unwired Planet on their Handheld Device Markup
Language (HDML), a language similar to HTML but focused on small-screen devices such as
PDAs and mobile phones. The phone companies were also working, in conjunction with the
World Wide Web Consortium (W3C), on specifications to provide wireless transmission of
Internet data.
All this proprietary-based work came to a head in 1997 when a US network operator called
Omnipoint received several different responses from the different phone companies to a tender
request they had issued for the supply of wireless information services. Omnipoint recommended
that the various vendors get together and define a common standard. Thus the WAP Forum was
born with a mission to create a global wireless specification to work across the different wireless
technologies.
WML was formed by utilizing many of the concepts in Phone.com's HDML within the industry-
standard framework of XML, practically guaranteeing its long-term success and ability to evolve
without limitation.
The WAP Forum published the WAP 1.0 specification for product interoperability and
content/application development in 1998, having based their work on Internet standards and
technology. After WAP 1.0 was released, the WAP Forum was then opened up for membership
by all organizations interested in the area.
As of early 2001, there were well over 600 members from the leading wireless device
manufacturers, wireless operators, and software development companies. By 2003, it is predicted
that over 90 percent of all mobile phones dispatched will be equipped with a WAP browser.
The goals of the WAP Forum are to bring Internet content and advanced data services to wireless
portable devices; create a global open protocol that works across all wireless technologies; allow
the creation of applications and content that can be scaled across a wide range of devices and
wireless bearer networks; and use existing standards and technology wherever appropriate.

The WAP Architecture

WAP's architecture applies Internet standards to microbrowser technology with the wireless
device controlling how server WAP content is displayed. The protocol model is based directly on
the familiar World Wide Web model, but has been optimized to provide functionality across
wireless networks between wireless terminals.
The architecture is designed so that only the minimum of memory and processing resources are
used by the wireless device, allowing the greatest range of low intelligence handsets to be
equipped with the microbrowser. However, the architecture also allows more sophisticated
devices to take advantage of higher-quality content delivery through the inclusion of animation,
graphics, and scripting.
The WAP programming model is based upon the very flexible and powerful World Wide Web
programming model. In this model, applications and content are presented in standard data
formats and are read by Web browsers. The Web browser sends requests for data objects to a
Web server, and the Web server responds with the data encoded using the standard formats.
Figure 1.3 illustrates this process.
Figure 1.3: World Wide Web programming model

The World Wide Web standards specify a standard naming model. Under this model, all servers
and content are named with an Internet-standard Uniform Resource Locator (URL). It enables
Web browsers to correctly process content based on a specific content type. Also defined are
standard content formats such as Hypertext Markup Language (HTML) and standard protocols
such as the Hypertext Transport Protocol (HTTP), which allows any Web browser to
communicate with any Web server.
The World Wide Web standards also define three types of servers: an origin server on which
given WAP content sits or is to be dynamically created; a proxy server, which acts both as a
server and a client for the purpose of making requests on behalf of other clients; and a gateway
server, which acts as an intermediary for some other server.
The proxy server normally resides between clients and servers that have no means of direct
communication. Requests are serviced by the proxy program or passed on, with possible
translation, to other servers. The proxy server implements the client and server requirements of
the World Wide Web specifications. Unlike a proxy, a gateway receives requests as if it were the
origin server for the requested resource. The requesting client may not be aware that it is
communicating with a gateway.
The WAP programming model is simply standard Web programming with a WAP gateway in the
middle of the request/response cycle. A cell phone or other wireless terminal requests, in byte
code, a given URL; the WAP gateway server decodes and decompresses this, then sends it on to
the appropriate origin server as an ordinary HTTP request. The process is then repeated, in
reverse, on the response side of the cycle.
This programming model has ensured that application developers have a smaller learning curve
with a proven architecture and the ability to leverage existing tools. The WAP programming model
has had to take into account the more restricted limitations of the wireless environments, but,
wherever possible, existing standards have been used or have been adopted as the starting point
for the WAP technology.
Figure 1.4 illustrates this WAP programming model. A user presses a key on their WAP phone.
The key has a URL request assigned to it, which the client (user agent) passes to the WAP
gateway using the WAP protocol. The WAP gateway then creates a normal HTTP request for the
specified URL and passes it on to the origin server for processing. The URL may refer to a static
file or some form of script application. If a static file has been referenced, the origin server adds
an HTTP header to the file. If a script application has been specified, then the origin server runs
the application. The origin server then returns the WML document (deck) incorporating the HTTP
header or any output resulting from a script application. The WAP gateway then verifies the HTTP
header and the WML content, encodes them into binary format, and creates a WAP response
containing the WML that it sends to the client. Upon receipt of this response, the client processes
it and displays the first card of the WML deck to the user.
Figure 1.4: The WAP programming model

So, WAP applications and content use formats based upon World Wide Web formats, and a set
of standard communication protocols is used to transport content. The WAP microbrowser acts in
the same way as a Web browser, coordinating the user interface.
WAP uses standard World Wide Web URLs to identify WAP content on origin servers and identify
local resources in a device. It uses content typing consistent with World Wide Web typing,
allowing user agents to process the content based on its type, and standard World Wide Web-
based content formats for display, calendar, electronic business-card objects, images, and a
scripting language. It also uses standard communication protocols, allowing the communication of
browser requests from the wireless terminal to the network Web server.

The WAP Protocol

WAP is a layered communications protocol, an implementation of which is embedded in all WAP-
enabled user agents. Its structure is very similar to the well-established International Standards
Organization (ISO) network model with a transport protocol similar to the generally fixed-line
HTTP. However, in this case, it is focused on broadcast requirements, which use less bandwidth.
The WAP protocol architecture is shown in Figure 1.5 alongside a typical Internet Protocol stack.
It consists of layers, which describe and specify the application/browser (WAE), sessions (WSP),
transactions (WTP), security (WTLS), transports (WDP), and bearers (SMS, USSD, CSD, IS-136,
CDMA, etc.).

Figure 1.5: WAP and Internet Protocol stacks

Following are brief descriptions of the main features of the Wireless Application Protocol layers.

Wireless Application Environment (WAE)

The WAE is the top layer of the WAP stack and is of most interest to content developers because
it contains, among other things, device specifications and the content development programming
languages, WML and WMLScript. It is an application environment that is based on a combination
of mobile telephony technologies and the World Wide Web. The purpose of the WAE is to
establish an environment to build applications and services. The WAE includes a microbrowser
environment that defines how the wireless device interprets and presents WML and WMLScript. It
also contains components that specify the following:
§ WML for creating WAP applications
§ WMLScript to enhance the logic capabilities of WML
§ Wireless Telephony Application Interface (WTAI), which provides telephony services
for WML decks running on phone-based devices
§ Content formats that define a set of data formats, including images, phone book
records, and calendar information
WAE depends upon a WAP-compatible proxy server to translate between WAP and HTTP
transactions and WAP and Internet Protocols.

Wireless Session Protocol (WSP)

The WSP is a sandwich layer that links the WAE to two session services: one connection-
oriented service that operates above the Wireless Transaction Protocol and one connectionless
service operating above the Wireless Datagram Protocol. It is basically a binary-formatted
tokenized version of HTTP, designed to provide low bandwidth browser handling on long latency
networks. Unlike HTTP, WSP has been designed by the WAP Forum to provide fast connection
suspension and reconnection. It has also been designed to provide content push capabilities that
allow unsolicited transmission of data to user agents, which in turn allows WAP device users to
be alerted, for example, to incoming e-mails, telephone calls, and faxes.

Wireless Transaction Protocol (WTP)

The WTP runs on top of a datagram service such as User Datagram Protocol (UDP) and is part
of the standard suite of TCP/IP protocols used to provide a simplified protocol suitable for low
bandwidth wireless stations. It offers three classes of transaction service: unreliable one-way
request, reliable one-way request, and reliable two-way request response. WTP supports protocol
data unit concatenation and delayed acknowledgment to help reduce the number of messages
sent, and to attempt to optimize the user experience by providing the information that is needed
when it is needed.

Wireless Transport Layer Security (WTLS)

WTLS incorporates security features that are based upon the established Transport Layer
Security (TLS) protocol standard. It includes data integrity checks, privacy, service denial, and
authentication services. Developers can access WTLS by using HTTPS instead of HTTP in the
URL.

Wireless Datagram Protocol (WDP)

The WDP allows WAP to be bearer-independent by adapting the transport layer of the underlying
bearer. The WDP presents a consistent data format to the higher layers of the WAP protocol
stack, thereby offering the advantage of bearer independence to application developers.

Bearers
Below the WDP sit all of the bearer networks. These include Short Message Service (SMS), a
facility for sending short messages; Unstructured Supplementary Service Data (USSD); Code
Division Multiple Access (CDMA), for the reuse of scarce radio resources in adjacent areas; and
Cellular Digital Packet Data (CDPD).
Through the Internet Protocol stack, the WAP client communicates with the WAP gateway, which
sits between the wireless carrier's network on one side and the public Internet or corporate
intranet on the other. Gateways can be located within carrier or corporate firewalls or both. In
addition to taking care of various housekeeping tasks such as keeping track of the WAP client's
bookmarks and managing its cache, the WAP server handles the interface between the two sets
of network protocols, wireless (WAP) and wired (TCP/IP).

WAP Standards
As much as possible, WAP uses existing Internet standards for the basis of its own architecture
and is designed to allow standard Internet servers to provide services to wireless devices.
However, Internet standards such as HTML, HTTP, TLS, and TCP, which require large amounts
of mainly text-based data to be sent, are inefficient over wireless networks. Traditional HTML
content cannot be displayed well on the small-sized displays of mobile phones and pagers, and
navigation around and between screens is not easy in one-handed mode. So Internet standards
such as HTML, HTTP, TCP, and TLS are not appropriate for the restrictions associated with
wireless networks.
WAP does, however, use many other Internet standards such as eXtensible Markup Language
(XML), User Datagram Protocol (UDP), and Internet Protocol (IP) to communicate with wireless
devices. So WAP is based on familiar standards such as HTTP and TLS, but has been optimized
for the constraints of the wireless environment. For example, a WAP gateway is required to
communicate with other Internet nodes using HTTP, and the WAP specification requires devices
to use standard URL addressing to request services.
So WAP has been optimized with the restrictions of the wireless environment in mind. It is
designed for low bandwidth and long latency, and uses binary transmission for greater
compression of data. WAP sessions deal with intermittent coverage and operate using IP over a
large variety of wireless transports whenever possible.
It is important that WAP standards complement existing standards. For example, instead of the
WAP specification designating how data is transmitted over the air interface, it is designed to sit
on top of existing standards so that the bearer's standard is used with the WAP protocol.
The WAP Forum works closely with the World Wide Web Consortium and other bodies such as
the European Telecommunications Standards Institute (ETSI), the Cellular Telecommunications
Industry Association (CTIA), and the Internet Engineering Task Force (IETF) to ensure that the
future versions of HTML, HTTP, and TCP take the special needs of wireless devices into account
and can be supported in the WAP framework. The WAP Forum also works closely with these
bodies and others as they become members of the Forum to address the enhanced capabilities
of third generation (3G) wireless networks expected to emerge around 2003 and 2004. Some
countries, such as Japan and Finland, plan to have 3G services in use as early as 2001.
When the WAP Forum identifies a new area of technology with no existing standards
specification, it works to submit its specification to related standards groups, believing that active
participation leads to the best standards. With this approach, the WAP Forum hopes to produce
open, not proprietary, standards through industry consensus and with no one vendor receiving
favorable treatment. To date, the WAP Forum's membership role of contributing companies
stands at over 100 who subscribe to the notion of the development of open standards as the best
way to produce solutions for wireless Internet access.

WAP Devices
As well as being air-interface independent, the WAP specification is also device independent,
specifying the minimum functionality a device must have, but designed to accommodate any
functionality above that minimum.
A WAP device is a combination of hardware and software capable of running a WAP-compliant
microbrowser such as a WAP-enabled mobile phone or a PDA. The use of proxy technology and
compression in the network interface reduces the processing load so that inexpensive CPUs can
be used in the handset, further reducing power consumption and extending battery life.
A PC can also be used as a WAP device if you download a WAP phone emulator from one of the
developer sites. The emulator allows you to use a virtual phone on your desktop. Some major
suppliers, such as Ericsson, Nokia, and Openwave, have developer sites where you can
download software development kits (SDKs) containing WAP emulators.
A WAP phone can run any WAP application in the same way that a Web browser can run any
HTML application. Once you have a WAP phone, you can access the Internet simply by entering
URLs (or clicking bookmarked ones) and following the links that appear.
Using these devices, easy and secure access to Internet content and services such as banking,
leisure, and unified messaging is made available. Furthermore, access is not restricted to the
Internet; WAP devices will be able to deal with intranet information in the same way as Internet
content because both are based upon HTML. This gives corporations the means of offering their
employees information related to their work at any time, while on the move. This may also be
extended to the corporation's customers and suppliers by making restricted access to company
extranets available, thereby opening up the supply chain to interrogation and analysis. Of course,
such corporate information will need to be reconfigured into a format suitable for small-screen
viewing by reprogramming in WML or passing the pages through special HTML-to-WML filters.
With the wide range of WAP-enabled wireless devices now hitting the market, users will have
significant options available to them when purchasing terminals and the applications they support.
Following is a selection of WAP phones that have been announced recently:
§ Nokia 7110 and Nokia 7610 These two mobile phones are physically identical. The
Nokia 7110 is targeted at the 900/1800MHz GSM market (Europe, Africa, Asia Pacific),
whereas the Nokia 7610 is targeted at the 900/1800MHz TDMA market (USA). The user agent
in both models is Nokia's WAP1.1 microbrowser. Both phones support WTLS.
§ Motorola Timeport P7389 The Timeport is a tri-band 900/1800/1900MHz GSM
mobile phone that can be used in much of the world. It uses the UP.Browser 4.x, supporting
not only WML and WMLScript 1.1, but also HDML 3. The Timeport supports WTLS.
§ Mitsubishi Trium Geo The Trium Geo was the first pre-pay WAP phone available.
It's marketed by the UK carrier BT Cellnet and is notable for allowing the user to optionally
disable WMLScript processing. Like most of the initial WAP phones, it does not support WTLS.
§ Sony CMD-Z5 Sony's Z5 is a dual-band 900/1800MHz GSM mobile phone
containing Microsoft's Mobile Explorer, which is both a WML microbrowser and an HTML
browser. It, too, does not support WTLS.
Device manufacturers can guarantee that their applications were developed to run on equipment
that has the minimum functionality specified by the WAP specification while adding features that
go beyond this minimum.
Because the WAP specification is so open, the services available to these devices will be wide-
ranging in their nature. Information will be available via both push and pull technologies, and
users will be able to interact with services by both voice and data. However, as the screen sizes
and current speed and processing limitations make the types of services offered restrictive, it's
unlikely that we'll see current Web-browsing patterns replicated via WAP-enabled devices until
bandwidth capabilities significantly increase. Short of an increase in bandwidth, the user-interface
consideration is unlikely to change in the short term as manufacturers strive to design devices
that are light and fit comfortably in the palm of the hand. Therefore, the type of information service
that content providers will offer in the short term will be real-time, specific services such as news,
weather, stock prices, and ticketing.

The Future
In the next few years, mobile phones will start to benefit from very high bandwidth capabilities.
Two-and-a-half and third generation communications systems (2.5G/3G) will allow enhanced
services such as full-motion video images, multimedia, high fidelity sound, and fast access to the
Internet. The 2.5G/3G systems will allow much higher capacity and data rates than can be offered
by the restricted bandwidth currently available.
These wireless devices will be supported by a number of emerging technologies, including the
following:
§ GPRS (General Packet Radio System) A packet-switched wireless protocol with
transmission rates from 115Kbps to 171Kbps. It will be the first service available to offer full
instant wireless access to the Web. It will require new handsets to support the higher data
rates. A main benefit is that users are always connected and online, and will be charged only
for the amount of data that is transported. A user can make and receive voice calls while at the
same time downloading data. For GSM providers, this new technology will increase data rates
of both circuit switching (High Speed Circuit Switched Data [HSCSD]) and packet switching
(GPRS) by a factor of 10 to 15 times.
§ EDGE (Enhanced Data Rate for GSM Evolution) A higher bandwidth version of
GPRS with speeds of up to 384Kbps, or twice that available from GPRS alone. It evolved from
GSM, which is the prevailing standard throughout Europe and the Asia Pacific region—some
50 percent of the world's population. For GSM providers, this new technology will increase
data rates of both circuit switching (HSCSD) and packet switching (GPRS) by a factor of 20 to
30 times.
§ HSCSD (High Speed Circuit Switched Data) A new high-speed implementation of
GSM data techniques. It uses four radio channels simultaneously and will enable users to
access the Internet via the GSM network at very much higher data rates than at present. Data
rates can be transmitted at 38.4Kbps or even faster over GSM networks.
§ UMTS (Universal Mobile Telecommunications System) UMTS will allow a future
mass market for high-quality wireless multimedia communications that will approach two billion
users worldwide by the year 2010. Scheduled to launch commercially in 2002, it is set to be
the technology that will allow the emergence of a new wireless Information Society. It will
deliver low-cost, high-capacity wireless communications, offering data rates of 1Mbps to
2Mbps with global roaming and other advanced UMTS services.
§ Bluetooth A specification for short-range radio links between wireless devices (a low-
power radio technology being developed to replace cables and infrared links with wireless
transceivers fitting onto a single chip). Devices such as printers, desktops, mobile phones, and
PDAs will use the technology, and it has the potential to be used for wireless LANs. It is a de
facto standard with a throughput of around 1Mbps, and delivers opportunities for rapid ad hoc
connections and the possibility of automatic connections between devices. For example, a
user could walk into their office and have their mobile phone's address book automatically
synchronize with their PC's address book. Bluetooth is considered complementary to WAP
technology, and when used together, they open up an unlimited variety of applications, such
as long-distance (WAP) remote control of home and office devices.
Note that all of these emerging technologies center around significant increases in the bandwidth
available to wireless devices.
So what is the future for WAP? It has been designed to be independent of the underlying network
technology. The original constraints WAP was designed for—intermittent coverage, small
screens, low power consumption, wide scalability over bearers and devices, and one-handed
operation—are still valid in 2.5G and 3G networks.
The rapid growth of the use of the Internet and the huge growth of the use of wireless
technologies are creating a demand for wireless access to the Internet, intranets, and other data
networks. People want at least the same speed and power as they can currently achieve when
using the Web via a desktop (and more) as they are offered connection technologies such as
ISDN, with bandwidths of around 64/128Kbps, and the potential high-speed connections that will
be available with the introduction of much faster services such as GPRS, EDGE, and eventually
3G systems.
What attracts the network operators is that WAP is a low-cost network upgrade that can be
integrated seamlessly with no downtime on the network infrastructure. And bridging 2.5G
technologies such as GPRS can be upgraded to 3G standards, ensuring that an operator's
investment is protected. In the meantime, we must live with the restrictions, and it is reasonable
to expect WAP to develop into optimized support for multimedia applications and continue to be
relevant over the short and medium term.
In this chapter, you've been introduced to some key features such as WAP, WML, WMLScript,
and the WAP architecture. WAP standards and devices have also been discussed together with a
look at what the future holds in this quickly moving market. The next chapter, "Getting Started,"
will focus on WML and get you going with your first WML applications, showing you the tools
you'll need to develop, implement, view, and test WML applications.

Chapter 2: Getting Started

The aim of this book is to guide you through the process of understanding how to use the
Wireless Markup Language (WML) to create services that can be accessed on any WAP-enabled
wireless device when supported by the scripting language WMLScript. This chapter gets you
started on this by introducing you to the WML structure and the tools you'll need to start
developing and viewing your first WML programs. You'll write and test your first simple program,
and you'll be introduced to the example application you'll be developing throughout the rest of the
book.

WML Structure
This section introduces you to the main elements you need to understand before you can get
started with WML. It discusses key concepts such as how WML is structured into decks made up
of one or more cards and how each card is composed of components such as tags, elements,
and variables.

Cards and Decks

WML applications use a card and deck metaphor. A user interaction is represented by a card,
while a complete task is represented by a deck. Applications can be thought of as a series of
tasks or a collection of one or more decks.
A deck is the smallest unit of WML that a Web server can send to a microbrowser, and it consists
of one or more cards with which a user is likely to interact. (A WML deck is really just a single file
with the WML extension. That's why it's the smallest unit the server can send!) Figure 2.1
illustrates the card and deck structure. When a user agent receives a deck, it usually activates the
first card in the deck, although you can direct it to any card in the deck. Depending on the card
definition, the user can respond by entering text or choosing an option. WAP-compliant wireless
devices with larger displays typically present each card as a single screen. Some smaller devices
present each card as a collection of screens.

Figure 2.1: The card and deck structure

As a deck consists of one or more cards, and a single interaction between a user agent and a
user is a card, multiple screens can be downloaded from the server to the client in a single
transaction. Using WMLScript, user selections or entries can be routed to and handled by already
loaded cards, thereby eliminating excessive communication with remote servers and improving
performance.
The task performed by a deck might be, for example, the input of a set of specific requirements
for booking a theater ticket. The deck might contain one card prompting the user to enter their
choice of show, one prompting them to enter the date of the show, another prompting them to
enter the time of the show, and so on. When the collection of card activities making up the deck is
completed, the data would be sent to the server, and the next stage of the process would be
activated. Another deck containing the next set of user interactions would be sent back from the
server to the user's device.
Let's take a look at a sequence of events that might occur in a simple application used for
accessing a user's bank details.
The user of the application enters the service's URL, probably through a bookmark, and the bank
application's server transmits a deck to the user's wireless device. The deck might contain a
Greeting card and two additional cards requesting a username and a password.
The user responds by entering their username and password, and the device's microbrowser
reconnects to the server and passes the input to a program known as a Common Gateway
Interface (CGI). This software verifies the user, gathers their specific account details, and formats
a new deck.
The new deck is then sent back to the user's device with an Account Information card linked to a
Search card and an End Session card. The user can then either end the session by selecting the
End Session card or request a search of their account data by selecting the Search card. If the
user selects the Search card, they need to enter search criteria and make a request. The server
is accessed, the required data is gathered, and a new deck is formatted. A new deck containing a
Search Result card, and additional Search and End Session cards, is transmitted back to the
user's device. The process proceeds until the user ends the session by selecting the End Session
card.
WML defines elements and attributes that let you specify the user-interface components, or the
cards. Elements and attributes will be discussed further in following sections. Wireless device
microbrowsers can navigate from one card to another.
A card can specify multiple user actions by including one or more of the following:
§ Formatted text, including text, images, and links
§ Input elements, which let the user enter a string of text, including numbers
§ Fieldset elements, which act as organizational containers for other elements
§ Select elements, which let the user choose from a list of options

Elements
WML is defined by a set of elements that specify all markup and structural information for a WML
deck. Elements are identified by tags, which are each enclosed in a pair of angle brackets. Unlike
HTML, WML strictly adheres to the XML hierarchical structure, and thus, elements must contain a
start tag; any content such as text and/or other elements; and an end tag. Elements have one of
the following two structures:
§ <tag> content </tag>
This form is identical to HTML.
<tag/>
§ When an element cannot contain visible content or is empty, such as a line break,
this form can be used.
Table 2.1 lists the majority of valid elements. For details on all elements, refer to Appendix A,
"WML Reference."
Table 2.1: Valid WML Elements
Category WML Elements Purpose
Decks and cards card Defines a card
template Defines a template
head Defines head information
access Defines access control information
meta Defines meta information
Events do Defines a do event handler
ontimer Defines an ontimer event handler
onenterforward Defines an onenterforward handler
onenterbackward Defines an onenterbackward handler
onpick Defines an onpick event handler
onevent Defines an onevent event handler
postfield Defines a postfield event handler
User input input Defines an input field
select Defines a select group
option Defines an option
 optgroup Defines an option group
fieldset Defines a set of input fields
Text formatting br Defines a line break
p Defines a paragraph
table Defines a table
tr Defines a table row
td Defines a table cell (table data)
Tasks go Defines a go task
prev Defines a prev task
refresh Defines a refresh task
noop Defines a noop task
Variables setvar Defines and sets a variable
timer Defines a timer
Anchors a Defines an anchor
anchor Defines an anchor
Images img Defines an image

Attributes
Attributes describe various aspects of the element. Some attributes are mandatory, while others
are optional and may have default values. You can include attributes in many WML elements.
You always specify attributes in the start tag of an element, using the following syntax:
<tag attribute1="value1" attribute2="value2"
attribute3="value3"...>

You separate each attribute value pair with white space, which may be a tab, new line, carriage
return, or space character, and you must enclose the value in double quotation marks ( ).
Attribute names must be lowercased.

Comments
As with most programming languages, WML provides a means of placing comment text within the
code. Comments are used by developers as a means of documenting programming decisions
within the code to allow for easier code maintenance. WML comments use the same format as
HTML comments and use the following syntax:
<!-- a comment -->

The WML author can use comments anywhere, and they are not displayed to the user by the
user agent.
Some emulators may complain if comments are placed before the XML prologue. The prologue is
the first few lines that define the document type and version. (See "The Deck Structure" later in
this chapter for more on the prologue.) Note that comments are not compiled or sent to the user
agent, and thus have no effect on the size of the compiled deck.

Variables
Because multiple cards can be contained within one deck, some mechanism needs to be in place
to hold data as the user traverses from card to card. This mechanism is provided via WML
variables. Variables can be created and set using several different methods. Following are two
examples:
§ The <setvar> element The <setvar> element is used as a result of the user
executing some task. The <setvar> element can be used to set a variable's state within the
following elements: <go>, <prev>, and <refresh>. The following element would create a
variable named a with a value of 321:
§ <setvar name="a" value="321"/>
§ The input elements Variables are also set through any input element (input,
select, option, etc.). A variable is automatically created that corresponds with the named
attribute of an input element. For instance, the following element would create a variable
named b:
§ <select name="b" title="B Value:">

Using Variables
Variable expansion occurs at runtime, in the microbrowser or emulator. This means it can be
concatenated with or embedded in other text. Variables are referenced with a preceding dollar
sign, and any single dollar sign in your WML deck is interpreted as a variable reference.
<p> total price is $$ $(total) </p>

Note WML is case sensitive. No case folding (the forcing of text to uppercase or lowercase)
is performed when parsing a WML deck. All enumerated attribute values are case sensitive.
For example, the following attribute values are all different: id="Card1", id="card1", and
id="CARD1".

The Deck Structure

A deck structure starts with a prologue that is followed by an optional header and then a
sequence of cards. The WAP server uses the prologue to manage the compilation of WAP
programs. As all WML programs are based on XML, they must always begin with a valid XML
prologue, which for WML 1.1 is as follows:
<?xml version="1.0"?>
<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN"
"http://www.wapforum.org/DTD/wml_1.1.xml" >

The prologue is followed by the body of the deck, starting with the <wml> element. WML consists
of a set of elements that may contain attributes. Attributes may, themselves, contain further
elements. All elements have a unique code tag. For example, the <card> element has the
following syntax:
<card
id="ID"
newcontext = "true | false"
 onenterbackward = "URL"
onenterforward = "URL"
ontimer = "URL"
ordered = "true | false"
title = "string"
>
You write content here.....

</card>

In this case, all attributes are optional and are used to describe things such as a unique identifier
for the card. A card element can contain a mix of processing instructions, formatting information,
and displayable content.
When a WAP user agent receives a deck, it searches the deck-level elements, looking for the first
card in the deck. It then examines the attributes and displays its content.
The program proceeds in response to user input or other events, and a deck is often linked to
other decks. Control of the application is allowed by the definition of different types of tasks that
affect the execution order of the decks. Tables and binary bitmapped images can also be
displayed.
WML handles input and output, content rendering, and event processing but has no serious
processing functionality. Therefore, WMLScript code may be referenced to enhance the
functionality of the application. A WAP browser must therefore contain a WMLScript Virtual
Machine (VM) to run the compiled script. WMLScript lets you define function operations such as
flow control statements (e.g., if, while, for), and it lets you call assignment statements and
comparison operations.

Installing an SDK
To test and develop your WML code, you will need to install a software development kit (SDK) or
microbrowser emulator. You shouldn't expect to write WML code without testing it on some kind
of microbrowser, and the SDKs are very useful for testing your WML pages even if you have your
own WAP-enabled phone or other device. The SDK you choose will depend upon a variety of
factors, such as the wireless devices you want to support, the features you need, and your
personal preferences. Before embarking on a major project, it's a good idea to consult the
product suppliers and other developers before making your choice. However, to ensure your code
will work correctly in as many microbrowsers and WAP-enabled devices as possible, it may be
best to install several of the main SDKs available.
Note It's important to understand that the results displayed by the examples given in the
book may not look exactly the same as the figures and graphics shown. This if often true
even between different versions of the same emulators. What's important is that the general
functionality is the same, meaning that although it may look and feel a little different when
used, it still performs the same. Incidentally, this problem also exists when using WAP-
enabled devices, which is why extensive testing on all supported devices is so important.
There are a number of SDKs available to assist you in the speedy development of WAP-based
services. These SDKs usually contain a microbrowser emulator, although a range of self-standing
emulators are being developed by various WAP-related organizations. Anywhere YouGo.com is
creating a comprehensive list of WAP development tools, and the main ones listed to date are
shown in
Table 2.2.
Table 2.2: WAP Development Tools
Supplier Description
Ericsson The Ericsson WapIDE SDK 2 is an Integrated Development
http://www.ericsson.com/ Environment (IDE) for developing WAP services. It consists
of three main components: a WAP browser, an Application
Designer, and a Server Toolset. Use the following link to
access this kit:
http://www.ericsson.com/developerszone/.

Motorola The Mobile Application Development Kit (Mobile ADK)

http://www.motorola.com/ allows developers to create their own add-on voice and data
solutions. It consists of tools for both WAP and VoxML
applications. Use the following link to access this kit:
http://www.motorola.com/developers/wireless/.
This ADK has some limiting factors. One is the huge
download; another is that it needs a recent (mid-2000)
version of Internet Explorer.
Nokia The Nokia WAP Toolkit is a generic software tool that
http://forum.nokia.com/ enables developers to create and test application software
that will run on a Nokia WAP server. The Toolkit can also be
used to demonstrate WAP applications. It provides an easy
environment in which developers can write, test, and debug
applications on a PC-based emulator. Use the following link
to access this Toolkit:
http://www.nokia.com/corporate/wap/sdk.html.
Note that the Nokia Toolkit, because it's written in Java,
runs not only on the Windows platform, but also on Linux,
Solaris, etc.
Openwave Now called Openwave after their merger with Software.com,
http://www.openwave.com/ Phone.com's UP.SDK is a free SDK that allows Web
developers to quickly and easily create HDML and WML
information services and applications. The SDK includes an
emulator that accurately simulates the behavior of an
UP.Browser-enabled device. Phone.com also provides a
publicly available UP.Link. Use the following link to access
this kit: http://developer.openwave.com/

Dynamic Systems Research Wapnet provides an SDK with a set of comprehensive tools
Ltd. (Wapnet) for developing WAP applications. Included are the WAR
http://www.wap.net/ (Wireless Application Reader) browser together with a set of
WML and WMLScript source code examples. Use the
following link to access this SDK: http://www.wap.net/.
Inetis The Inetis DotWAP SDK allows fast and simple WAP site
http://www.inetis.com/ construction without any WAP or WML knowledge. It runs
on Win32 platforms and is freeware. Use the following link
to access this SDK: http://www.inetis.com/.

Note The files in Table 2.2 are sometimes very slow to download because they can be very
large—as much as tens of megabytes! Be careful in selecting your SDK, because not all
versions are free, and some require extra software.
The Nokia WAP Toolkit requires the latest release of Java. Check the Nokia site for more details
and be prepared to register with Nokia as a WAP developer (for free) before entering the Nokia
Forum, where you will find the links to the software.
The Ericsson SDK is also a large download because it includes a copy of the Xitami intranet Web
server, although you do not have to install it if you already have it or a similar Web server
installed. A local host server such as Xitami will help with the creation of your WML pages, should
make loading pages quicker, and will allow the testing of dynamic content.
The Openwave UP.SDK is faster than either the Nokia or the Ericsson SDKs, although it may not
be as suitable for developing and testing dynamic WML pages. There is also a microbrowser
available from Openwave, but again, it is quite a large download. Their microbrowser uses a local
server with a full-screen-height browser display.

WAP Emulators
Instead of installing an entire WAP SDK, you can install a WML emulator. An emulator simply lets
you view the contents of your WML files as they would be seen on the screen of a WAP-enabled
device. In many cases, a WAP SDK will provide little more than a WML emulator together with
some example code. By using just an emulator, you will, therefore, still be able to see the output
of your WML code, and the download time will be much less.
Again, while the emulators do a great job, they are not perfect. Try a few different ones, and you
will quickly decide which you like the most. When the time comes to develop a real (commercial)
WAP site, you will need to do a lot more testing, first with other SDKs/emulators and then with all
the WAP-enabled devices you plan to support.
The following lists some of the WAP emulators that are available at the time of writing this book:
§ Klondike WAP Browser Produced by Apache Software
(www.apachesoftware.com). Klondike looks a lot like a Web browser and is therefore very
easy to use for beginners. You can access local WML files easily. It also supports drag-and-
drop, making local file use very easy.
§ M3Gate Produced by Numeric Algorithm Laboratories (www.numeric.ru). M3Gate
is a fast, stand-alone program that uses the Web browser as its gateway. It has full support for
WML, WMLScript, WBMP images, Unicode, bookmarks, Multiple Character sets, and a choice
of skins (additional handsets). It also supports drag-and-drop, making local file use very easy.
§ Yospace Produced by Yospace (www.yospace.com). WAP developers can use the
desktop edition of the emulator to preview WAP applications from their desktop, safe with the
knowledge that the emulator provides a reasonably faithful reproduction of the actual handset
products. You can plug in support for additional handsets as they become available (skins).
Yospace is bundled with a collection of simple command-line tools (e.g., WML encoder,
WMLScript compiler) for easy integration into your existing development environment.
 § EzWAP Produced by EZOS (www.ezos.com). EZOS provides EzWAP, the first
platform-independent WAP browser, which enables all kinds of computing systems to access
the wireless Internet: wireless devices (e.g., PDA, Pocket PC, PC Companions), wireless
computing and embedded systems, and PCs running Microsoft Windows NT, 2000, or CE.
§ WAPalizer Produced by Gelon (www.gelon.net). The script fetches WML pages
from WAP sites and converts them to HTML on the fly. In reality, it is not technically an
emulator, because it does not interpret WML code, but HTML. This means that you will be able
to view most WAP pages, but some pages, especially those with a lot of input forms, are very
difficult to convert to HTML. Gelon also has a range of other pseudo-emulators that look like
real WAP phones.
§ Ericsson R380 Emulator Produced by Ericsson
(www.ericsson.com/developerszone). The R380 WAP emulator is intended to be used
to test WML applications developed for the WAP browser in the Ericsson R380. The emulator
contains the WAP browser and WAP settings functionality that can be found in the R380.
§ WinWAP Produced by Slob-Trot Software Oy Ab (www.winwap.org). WinWAP is a
WML browser that works on any computer with 32-bit Windows installed (Windows95,
Windows98, and Windows NT). You can browse WML files locally from your hard drive or the
Internet with HTTP (as with your normal Web browser). It also looks and feels a lot like a
normal Web browser.
§ WAPman for Windows95/98/NT Produced by wap.com.sg
(www.wap.com.sg/downloads). The WAPman is a portable browsing device, combining
access to the Internet with the properties of a mobile phone. With its unique WAP gateway
structure, the WAPman has fast downloading capability and is highly compact and portable,
functioning as a wireless commerce and lifestyle portal.
§ WAPsilon Produced by Wappy (wappy.to). WAPsilon converts WAP sites to HTML
that can be viewed on their site or on their device. WAPsilon can be integrated into your Web
site or plugged into your browser. Like WAPalizer, it technically is not an emulator, because it
does not interpret WML code, but HTML.
§ Opera Produced by Opera (www.opera.no). Opera is actually an excellent HTML
Web browser that now also supports WML. An interesting idea, because it's very convenient to
browse both HTML and WML with the same product. This is one to watch.
§ WAPEmulator Produced by Wapmore (www.wapmore.com). Their emulator is
available on the Wapmore site. There is a new Netscape version that is not as functional as
the Internet Explorer version.
§ Wireless Companion Produced by YOURWAP.com (www.yourwap.com). With the
Wireless Companion, you may access any WAP and Web content over the Internet including
the free personal wireless services at YOURWAP.com.

Some Design Considerations

Wireless devices are limited by the size of their displays and keypads. It's therefore very
important to take this into account when designing a service. Typically, today's WAP-enabled
wireless devices have displays that range from sub-VGA graphics to screens that can display no
more than four lines of 32 characters. So as a WAP device application or service designer, you
must take this into account.
As this book goes to press, there are announcements of all types of amazing new WAP-enabled
devices that offer far better features, but as is usual practice with software development, it's wise
to support the minimum platform for the widest market appeal. It is, however, also possible to
detect the device type and offer the extra features where available.
Typical WAP services might include buying tickets, viewing train time tables, checking into flights,
and looking up things like sports results, stock values, and phone numbers. People accessing
such services are not going to use their devices to surf the Internet in the traditional sense, as the
restricted interface will not accommodate this way of working. So you must ensure that you keep
things simple and easy to use. You should always keep in mind that there are no standard
microbrowser behaviors and that the data link may be relatively slow, at around 10Kbps.
However, with GPRS, EDGE, and UMTS, this may not be the case for long, depending on where
you are located.
The following are general design tips that you should keep in mind when designing a service:
§ Keep the WML decks and images to less than 1.5KB.
§ Keep text brief and meaningful, and as far as possible try to precode options to
minimize the rather painful experience of user data entry.
§ Keep URLs brief and easy to recall.
§ Minimize menu levels to prevent users from getting lost and the system from slowing
down.
§ Use standard layout tags such as <big> and <b>, and logically structure your
information.
§ Don't go overboard with the use of graphics, as many target devices may not support
them.

A Simple WML Program

By now, we are assuming that you have downloaded and installed either a WML SDK or an
emulator. If you haven't done so, we suggest you do this now, so that you can write your first
WML deck. It contains just one card and will display the message "This is my first WML Card" in
your WML emulator (see Figure 2.2).

Figure 2.2: A one-card WML program

This test will enable you to see how your emulator accesses local files and check that it is
working as it should. When working with local WML files, it's best to select an emulator that
makes it easy to do so. Some emulators assume you only want to enter a remote URL. The best
ones for local file use will either remember the last open file folder or accept dragged-and-
dropped files. Both Klondike and M3Gate accept drag-and-drop files at this time.
Before going any further, decide which text editor you want to use to create your WML files. We
use Wordpad—it comes free with Windows95, 98, and NT, and includes most of the editing
functions you could ever need for editing WML files. Once you have decided which editor you are
going to use, use it to create an empty file named myfirst.wml.

Note If you are using Wordpad or Notepad, the DOC or TXT extensions, respectively, will be
appended to your file unless you specify another extension when saving the file. So, make
 sure to add the WML extension when saving. If you forget and the file is saved with the DOC
or TXT extension, just manually change the extension to WML.
Now that you have created your file, type the following text into it:
<?xml version="1.0"?>
<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN"
"http://www.wapforum.org/DTD/wml_1.1.xml" >
<wml>
<card id="First">
<p>
This is my first WML Card
</p>
</card>
</wml>

Tip If
you don't want to type this text, the file, myfirst.wml, is provided on the CD that comes
with this book—you can simply copy this file onto your hard drive.
Now, read the instructions provided with your emulator to find out how to open a WML file on your
hard disk and display its contents on your emulator. We recommend that you don't skip this test
and that you spend time getting to know how your emulator accesses local files—you will find this
essential for the early stages of creating and testing WML code as you'll use this mechanism to
test and view the results of your WML programs without having to download it from a Web server.

Testing Your Program

By creating and displaying the myfirst.wml file, you performed the simplest type of
test—creating a WML file locally on your hard disk, then viewing it using an emulator.
This is by far the most efficient way of developing and testing WML files. Since your aim is,
however, to develop a service that is going to be available to WAP phone users, you should
upload your WML files onto a server once you have developed them locally and test them over a
real Internet connection. As you start developing more complex WAP services, this is how you
will identify and rectify performance problems, which could, if left alone, lose your site visitors.
In uploading the file myfirst.wml to a server, you will be testing your WML emulator to see how
it looks and behaves, and checking your Web server to see that it is set up correctly. Now start
your emulator and use it to access the URL of myfirst.wml. For example, the URL might look
something like this:
http://ourwebsite.com/wapstuff/myfirst.wml

Configuring Web Servers to Deliver WAP Content

If you are using a commercial or free host/server, ask their technical support staff if they support
WAP (most already do). If not, you can ask them if they could do so. It's a very simple change.
If you need a server to host your WAP site, here are a few top-rated hosts that support WAP:
§ www.TierraNet.com
§ www.Verio.com
 § www.NetNation.com
§ www.Web2010.com
§ www.HiWay.com

If you have your own server, then you simply need to add support for the MIME types and
extensions listed in Table 2.3. Instructions follow on how to configure the two leading Web
servers.
Table 2.3: MIME Types for WML Files
MIME Type File Extension
text/vnd.wap.wml WML

text/vnd.wap.wmlscript WMLS

application/vnd.wap.wmlc WMLC

application/vnd.wap.wmlscriptc WMLSC

image/vnd.wap.wbmp WBMP
§ Apache This popular Web server runs predominantly on Unix or Linux systems, so
we're providing instructions for configuring such a server. Locate the file srm.conf, which is
usually in /etc/httpd/conf, and add the following lines to the file:
§ AddType text/vnd.wap.wml .wml
§ AddType text/vnd.wap.wmlscript .wmls
§ AddType application/vnd.wap.wmlc .wmlc
§ AddType application/vnd.wap.wmlscriptc .wmlsc
§ AddType image/vnd.wap.wbmp .wbmp
§ Save the file and restart Apache, for example, by issuing the command
/etc/httpd/bin/apachectl restart. Be aware that the ResourceConfig variable in
the httpd.conf file can override the srm.conf file, meaning you'll have to modify whatever
file that variable indicates instead of srm.conf.
§ If you do not have your own Apache server, but you know that the server you
use—for example, your ISP's Web server—is Apache, then all may not be lost. If your Web
server administrator hasn't disabled this feature for security reasons, you can achieve the
same results by writing a file called .htaccess containing the lines above to each directory
that contains your WML files. In fact, the .htaccess file is hierarchically cumulative—place it
in your root directory for it to apply to all subdirectories.
§ Microsoft IIS To configure a Microsoft IIS server to deliver WAP content, you need to
perform the following:
1. Open the Internet Service Manager console and expand the tree to view
your Web site entry. You can add the WAP MIME types to a whole server or individual
directories.
2. Open the Properties dialog box by right-clicking the appropriate server or
directory, then choose Properties from the menu.
3. From the Properties dialog, choose the HTTP Headers tab, then select the
File Types button at the bottom right.
4. For each MIME type listed earlier in Table 2.3, supply the extension with or
without the dot (it will be automatically added for you), then click OK in the Properties dialog
box to accept your changes.
The Example Application
Through the course of this book, we're going to develop an example application. The aim of this
approach is to demonstrate how you can use all of the various WML and WMLScript features in a
real environment instead of using just abstract examples. We'll build the site as we go through the
book. Each time a concept or feature is explained, it will be integrated into the example
application.
In the example application, you are going to create a WAP service for a cinema that will let users
review the movies currently being shown and book tickets for them via their WAP-enabled mobile
phones. The idea is that once the users have booked the tickets, they can just arrive on the night
of the movie and pick their tickets up without worrying about ticket availability and the
inconvenience of waiting to purchase them.

The First Steps

The following sections walk you through the site you're going to create. When you first log on, you
are presented with a series of choices, as shown in Figure 2.3.

Figure 2.3: The Choice card

Figure 2.3 demonstrates how you can present a list of options to users and let them choose one,
so that the appropriate card is displayed. In Figure 2.3, the View Movies option lists the movies
that are currently available. In our example, there are only two. See Figure 2.4.

Figure 2.4: A card listing movies

In Figure 2.5, you see that the card for each movie provides a short critique of the movie with an
option to book tickets for that particular movie.
Figure 2.5: Movie Critique card

Performing Some Validations with WMLScript

Until now, the whole example application has been created using WML. Now, WMLScript comes
into play. If a user chooses to book a ticket in either of the cards shown in Figure 2.5, a
WMLScript function is called that performs the following processing:
§ If the user has logged on to the system in the current session, a card appears that
lets them choose how many tickets they want to book for each row (the tickets in each row are
priced differently).

§ If the user has not yet logged on to the system in the current session, they are
presented with a logon screen that prompts them to enter their mobile phone number, followed
by a screen that asks for their password. By requiring such information at logon, the logon
screen provides security, which is important since the user is about to perform a financial
transaction (book a ticket).

§ When the user enters their phone number and password, these details are sent to the
server.

The Server Side Programming

In the next process, the WML code runs a servlet, written in Java, on the server. The servlet
checks whether the entered values exist on the server. If they do, they are stored in a file on the
server. If they do not, the user is prompted to register for the service, and the server then records
the values the user enters.
Once the user has registered or logged on, they are presented with the card requesting them to
enter the number of tickets they want to book in each of the rows A, B, and C, as shown earlier.
Once they have entered this information, the server is polled by calling a Java servlet to check
that the number of tickets they booked is still available. If they are not available, a response is
returned to the mobile phone telling them how many tickets are left in the row or rows that the
user specified and prompting them to reenter a number of tickets.
Once they have entered a valid number of tickets, a WMLScript function is called to perform the
following functions:
§ Calculating the total number of tickets booked
 § Calculating the total price of the booked tickets
Finally, the WMLScript function performs the following validations:
§ If the total price is less than the cost of one of the cheapest tickets (indicating no
tickets were booked), the following alert is displayed:

Once the validations have all been completed, the total price of the tickets booked is displayed on
the mobile phone, as shown in Figure 2.6.

Figure 2.6: Tickets Reserved screen

If the user chooses to book the tickets, a Java servlet is called on the server to check that the
user has enough money in their account to pay for the tickets. If they do, the total cost of the
tickets booked is deducted from their account.
As the Choice card shows back in Figure 2.3, the user has three choices when they first access
the FirstUnwired.com service:
§ View Movies
§ Ticket Prices
§ View Account
We've just looked at what happens when they choose the first option. The second option calls a
Java servlet on the server that retrieves the ticket prices from the server and generates the WML
code required to display these prices. Because the Java servlet generates the WML on the fly,
this is known as a dynamic WML page, as opposed to a fixed or static page that has been coded
by hand. Dynamic WML can be produced by a wide variety of server side technologies, such as
Perl, PHP, ASP, and others.
The third option calls a WMLScript function that tests to see whether the user has already logged
on to the service in the current session. If they have, a Java servlet is called that retrieves their
account information from the server, then generates the WML code required to display their
account details. If they have not, they are prompted to log on to the service before their account
details are displayed.
The example application performs a typical range of functions that a WAP service may perform.
Note that it is by no means complete—error trapping is minimal, and the security is not what you
would want to use in the real world. Furthermore, to keep the server side simple, all the data is
stored by the servlet using plain text files. In a real-world application, it's more likely that you
would be using a database for this type of work, such as MySQL, SQL Server, Oracle, and
others. What this application will do is get you started using WML and WMLScript. You will use all
the typical interactions between WML and WMLScript on the client side and some typical server
side interactions, too.
Once you have completed this book, you will be ready to develop real WAP services—that is, a
complete WAP site that anyone in the world with a WAP-enabled device can access! You will be
comfortable in the knowledge that you have already mastered many of the features that you'll
want to use in your WAP application and have all the information you need to take the next step:
getting your service online. In the next chapter, you will take your first step in that direction by
creating your first WML pages.

Chapter 3: Your First WML Pages

Overview
We've already had a brief look at WML and WMLScript. Now let's start looking at how we can use
WML to create a WAP site! In this chapter, we're going to examine some of the basic elements of
WML 1.1, including the following:
§ How to define cards
§ How to include and format text
§ How to include and format images
§ How to navigate with user agent buttons
§ How to use lists to navigate within a deck
While reviewing these basic elements, we'll also create a simple WAP site with a splash screen,
welcoming users to the WAP site. You no doubt have come across many Web sites that employ
splash screens. These are often full of gadgets and all sorts of files that take forever to download.
Naturally, with a WAP site, you should keep your splash page simple; otherwise, your visitors
may well run out of patience waiting for it to download and go elsewhere instead. We're going to
create a simple splash screen that will include our site name, FirstUnwired.com, and a company
logo.

Getting Started
So let's go! First, we'll need to create the file in which we'll add the WML. Open whichever tool or
editor you're going to use to develop your WAP site and create a new file named cinema.wml.
Note the WML extension, indicating this is a WML file.
Now that you have created the file, add the following lines (called the XML prologue) to the top of
it:
<?xml version="1.0"?>
<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN"
"http://www.wapforum.org/DTD/wml_1.1.xml" >

If you don't want to type this in, you can copy and paste it from the prologue.wml file on the CD
under the directory /Examples.

Tip
Alternatively, if the editor you are using supports macros or templates, you could define one
and have the editor create the XML prologue for you each time you start a new deck.
The WAP server uses the XML prologue to manage the compilation of WAP programs. As all
WML programs are based on XML, they must always begin with a valid XML prologue, which for
WML 1.1 is as that given above.
Now that you have entered the prologue, you can start using WML. The first thing you'll want to
do is define the beginning and the end of the WML deck, using the <wml> element.

Tip
Remember that a deck is simply a WML file that contains one or more cards that will be
downloaded to the user agent.
As with all elements, the <wml> element has a start and an end tag. It is structured as follows:
<wml>
WML deck contents
</wml>

Note When developing WML files, we find it useful to always put in both the start and the
end tags for each element at the same time. This prevents you from forgetting to put the end
tag of an element in and, subsequently, spending a lot of time trying to work out why your
WML won't work!
So let's put the <wml> element into cinema.wml. It should now look like this:
<?xml version="1.0"?>
<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN"
"http://www.wapforum.org/DTD/wml_1.1.xml" >

<wml>

</wml>

Now that you have defined the beginning and end of the deck, you can put the first card into it. A
card is defined by the <card> element, including the start and end tags. Before going any
further, we have to give the card a name. To specify a card's name, you use the id attribute. In
this case, the card will be named Splash, so enter <card id="Splash"> in the start tag.

Tip
There is no convention in WML for specifying which card is displayed first in the user
agent—the first card in the deck is always displayed first.
Your text should now look like this:
<?xml version="1.0"?>
<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN"
"http://www.wapforum.org/DTD/wml_1.1.xml" >

<wml>

<card id="Splash">

</card>
 </wml>

Formatting Text
We can now start entering the card contents. We are going to display the text "FirstUnwired.com"
together with a company logo.
Let's first look at how to enter the text "FirstUnwired.com." Any text in a card has to be within a
<p> element. Go ahead and add the <p> element containing "FirstUnwired.com."

Your text should now look like this:

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

<wml>

<card id="Splash">
<p>
FirstUnwired.com
</p>
</card>

</wml>

Let's now look at this in your SDK. Start your SDK and open the file cinema.wml. It should look
something like Figure 3.1.

Figure 3.1: The Splash screen

As far as splash pages go, even if we are limited by bandwidth, ours could use a bit of spicing up!
Let's add some formatting. The <p> element includes two attributes: align and mode. They
have the following syntax:
<p align="alignment" mode="wrapmode">
content
</p>

In this syntax, align is the alignment of the paragraph. This can be left, center, or right.
And mode is the wrap mode. By default, word wrapping is used. You can prevent word wrapping
by defining mode as nowrap.

Let's use the align attribute in the <p> element to define the alignment of the text as center
and also display "FirstUnwired.com" in bolded big typeface. To display text in bold, you use the
<b> element. To display text in a big font, you use the <big> element. You can nest elements
within other elements, so there is no problem in having the same text within several elements.
Note Not all user agents support the <big> element.

Now try adding the align="center" attribute to the <p> element and the <b> and <big>
elements to cinema.wml. You should end up with something like this:
<?xml version="1.0"?>
<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN"
"http://www.wapforum.org/DTD/wml_1.1.xml" >

<wml>

<card id="Splash">
<p align="center">
<b><big>FirstUnwired.com</big></b>
</p>
</card>

</wml>

The code should look like Figure 3.2 when displayed in your user agent.

Figure 3.2: Splash screen using formatted text

Adding Images to WML Cards

Let's finish the splash page with an image. The WML language allows you to include images in
formatted text.
Note Not all user agents currently display images. You can, however, write decks containing
images and send those decks to such devices.
You use the <img> element to include images in your WML cards. The image appears wherever
you put the <img> statement within the text.
The <img> element has the following syntax:
<img alt="text" src="url" localsrc="imgfile"/>

The alt attribute specifies the text to display if the user agent does not support images or cannot
find the specified image—rather than displaying an error message.
The src attribute specifies the URL of the image to display. The localsrc attribute specifies an
image that is stored in the user agent ROM (read-only memory) or the Web server. If you specify
a valid image in the localsrc attribute, the user agent ignores the src attribute.

WAP has its own graphic format, WBMP (Wireless BitMap). Some user agents may accept the
other Internet graphics formats, such as JPEG and GIF, but as WBMP is the de facto WAP image
format and is likely to be supported by the widest range of user agents, we recommend that you
use this.
We have included a file named funwired.wbmp on the CD under the directory /Examples.
Now add the <img> element to your WML file to include an image above the text
"FirstUnwired.com." You should end up with something like this:
<?xml version="1.0"?>
<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN"
"http://www.wapforum.org/DTD/wml_1.1.xml" >

<wml>

<card id="Splash">
<p align="center">
<b><big>FirstUnwired.com</big></b>
<img src="cinema.wbmp" alt="FirstUnwired.com"/>
</p>
</card>

</wml>

Moving Around
So far, we have only one card in our example. We now want to be able to go from the Splash
card to an Index card, letting users choose what they want to do. There are two basic ways in
which you can let users move from one card to another: by pressing a button on their mobile
phone or by choosing an option from a list.
In our example application, we are going to define a button on the user agent to display the next
card when it is pressed.

Navigating with User Agent Buttons

WML 1.1 defines a number of "buttons" that all WAP-compatible devices must support. We put
buttons in quotation marks because they do not necessarily have to be buttons per se—they are
actually commands that can be executed by any type of user interaction, such as pressing actual
buttons or an area on a touch-sensitive screen, or even using a voice command.
In our example, we are using buttons on a mobile phone. The button on the top-left side of the
keypad will be used as the Accept button, which is what we will use to let the user make an
affirmative choice. We'll leave the top-right button alone for now—this could be useful later for
performing actions based on the relevant context.
To define the action that is executed when a button is pressed, use the <do> element. The <do>
element looks something like this:
<do type="accept" label="Next">
<go href="#NextCard"/>
</do>

This <do> element defines the Accept button so that it is labelled "Next" on-screen, and when it is
pressed, the card NextCard is displayed using the <go> element with the href attribute. Instead
of displaying the NextCard (which, in this case, is in the same deck), we could display a card in
another deck, execute a WMLScript, or execute a program such as a Java servlet or Perl script.

Defining Buttons
Let's now create a new card in cinema.wml and define the Accept button in the Splash card so
that it displays the new card. We'll name the new card Index. Remember, to define a new card,
we use the <card> element. In the meantime, we'll leave the card empty. By adding the new
card, the deck cinema.wml will look like this:
<?xml version="1.0"?>
<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN"
"http://www.wapforum.org/DTD/wml_1.1.xml" >

<wml>

<card id="Splash">
<p align="center">
<b><big>FirstUnwired.com</big></b>
</p>
</card>

<card id="Index">
</card>

</wml>

Now, let's use a <do> element to display the new card, Index, when the Accept button is pressed
and give it the label "Enter." cinema.wml will now look like this:
<?xml version="1.0"?>
<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN"
"http://www.wapforum.org/DTD/wml_1.1.xml" >
 <wml>

<card id="Splash">
<do type="accept" label="Enter">
<go href="#Index"/>
</do>
<p align="center">
<b><big>FirstUnwired.com</big></b>
</p>
</card>

<card id="Index">
</card>

</wml>

Now, open cinema.wml. The first screen that is displayed should now look something like Figure
3.3.

Figure 3.3: Splash screen with redefined buttons

Navigating with Lists

Buttons aren't the only tool available to let users navigate between cards. You can also let users
choose options from a list on-screen, then display a card depending on the chosen option.
In WML, you have the choice of two types of lists: one that uses the <option> element nested
within the <select> element and another that uses the <go> element nested within the
<anchor> element. The difference between the two is in the presentation on-screen and the
mechanism for selecting an option.
The WML code for the first type of list, using the <option> element from within the <select>
element, looks like this:
<select name="choice">
<option onpick="#Movies"> View Movies </option>
<option onpick="#Prices"> Ticket Prices </option>
<option onpick="#Directions"> Directions </option>
</select>
Be sure to place the <select> element inside a <p> tag pair for it to work. The minimal code to
display the <select> list would look something like this:
<?xml version="1.0"?>
<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN"
"http://www.wapforum.org/DTD/wml_1.1.xml" >

<wml>

<card>
<p>
<select name="choice">
<option onpick="#Movies"> View Movies </option>
<option onpick="#Prices"> Ticket Prices </option>
<option onpick="#Directions"> Directions </option>
</select>
</p>
</card>

</wml>

The list will look something like Figure 3.4 when displayed on-screen.

Figure 3.4: List using the <option> element

The WML code for the second type of list, using the <go> element nested within the <anchor>
element, looks like this:
<anchor title="Movies">
<go href="#Movies"/>View Movies
</anchor>
<br/>
<anchor title="Prices">
<go href="#Prices"/>Ticket Prices
</anchor>
<br/>
 <anchor title="Directions">
<go href="#Directions"/>Directions
</anchor>

So, the minimum code required to implement this example of the <anchor> element would be as
follows:
<?xml version="1.0"?>
<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN"
"http://www.wapforum.org/DTD/wml_1.1.xml" >

<wml>
<card>
<p>
<anchor title="Movies">
<go href="#Movies"/>View Movies
</anchor>
<br/>
<anchor title="Prices">
<go href="#Prices"/>Ticket Prices
</anchor>
<br/>
<anchor title="Directions">
<go href="#Directions"/>Directions
</anchor>
<br/>
</p>
</card>

</wml>

The list will look something like Figure 3.5 when displayed on-screen.

Figure 3.5: List using the <anchor> element

The only real difference between the two types of lists is their presentation. Right now, let's look
more closely at the first type of list—using the <select> element.
Navigating with Selection Lists
What we want to do here is let users choose what they want to do next: choose a movie they
want to read more about and perhaps book tickets for it, or just view ticket prices.
First, we'll create two new cards, which we'll leave empty for the moment. They'll serve as cards
to which we can create links. We'll give them the card IDs Movies and Prices.
Go ahead, create the two new cards. Once you have created them, the file cinema.wml should
look like this:
<?xml version="1.0"?>
<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN"
"http://www.wapforum.org/DTD/wml_1.1.xml" >

<wml>

<card id="Splash">
<do type="accept" label="Enter">
<go href="#Index"/>
</do>
<p align="center">
<b><big>FirstUnwired.com</big></b>
</p>
</card>

<card id="Index">
</card>

<card id="Movies">
</card>

<card id="Prices">
</card>

</wml>

Now, we want to create a selection list using the <option> element within a <select> element
in the Index card. This will enable users to choose whether they want to view the list of movies
currently being screened or view the ticket prices, sending them to the appropriate card when
they make their choice. The <option> element has the following syntax:
<option title="label" value="value" onpick="url">

content
 </option>

In this syntax, title defines the label that is displayed for the Accept key, value defines the
unique value that will be assigned to the surrounding <select> name when the user chooses
the option, and onpick specifies the URL to open when the user chooses the option.

Let's now add two <option> elements nested within a <select> element in the Index card. The
first <option> element will have the title Movies, the card ID Movies for the onpick attribute,
and the text "View Movies."
Note WAP supports relative URLs. This means that since we are jumping to a card from
within the same deck, we have to enter only the card ID and not the URL in the onpick
attribute.
The second <option> element will have the title Prices, the card ID Prices for the onpick
attribute, and the text "Ticket Prices."
Tip
Before editing the cinema.wml file, note that the <select> element within which the
<onpick> element is nested must itself be nested within a <p> element.

Now you have all the information you need to create the selection list in the Index card, so give it
a go!
Once you have added the list to the Index card, the cinema.wml file should look something like
this:
<?xml version="1.0"?>
<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN"
"http://www.wapforum.org/DTD/wml_1.1.xml" >

<wml>

<card id="Splash">
<do type="accept" label="Enter">
<go href="#Index"/>
</do>
<p align="center">
<b><big>FirstUnwired.com</big></b>
</p>
</card>

<card id="Index">
<p>
<select>
<option title="Movies" onpick="#Movies">
View Movies</option>
 <option title="Prices" onpick="#Prices">
Ticket Prices</option>
</select>
</p>
</card>

<card id="Movies">
</card>

<card id="Prices">
</card>

</wml>

Now try viewing cinema.wml in your user agent. Navigate to the Index card, which should now
look something like Figure 3.6.

Figure 3.6: The Index card

Now that you know how to use selection lists, using the <onpick> element nested within the
<select> element, let's try using an anchored list to navigate.

Navigating with Anchored Lists

What we're going to do is create a list of two movies. (We never claimed that the example was
going to be totally realistic—you'll have to wait until you get to Chapter 7, "Making Your Service
Dynamic," for that!) In the meantime, we'll create a list of two movies using WML. These movies
are: Hello, Mary Lou and The Long Goodbye. Before creating the list, we'll create the two cards
that will display information about the two movies. This time, we won't leave the cards empty;
we'll include a short description of the film (remember to keep this very short, as it is targeting
users who'll be using mobile phones), the certification, and our own star rating. We'll let you
decide what description, certification, and star rating you give the movies! We'll give the new
cards the IDs Movie1 and Movie2.
Once you have added the two new cards, your cinema.wml file should look something like this:
<?xml version="1.0"?>
<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN"
"http://www.wapforum.org/DTD/wml_1.1.xml" >
<wml>

<card id="Splash">
<do type="accept" label="Enter">
<go href="#Index"/>
</do>
<p align="center">
<b><big>FirstUnwired.com</big></b>
</p>
</card>

<card id="Index">
<p>
<select>
<option title="Movies" onpick="#Movies">
View Movies</option>
<option title="Prices" onpick="#Prices">
Ticket Prices</option>
</select>
</p>
</card>

<card id="Movies">
</card>

<card id="Movie1">
<p>
Hello, Mary Lou
Adventure, comedy. Cert. 13. Star rating 3.
</p>
</card>
<card id="Movie2">
<p>
The Long Goodbye
Classic, romance. Cert. 13. Star rating 2.
</p>
</card>

<card id="Prices">
Random documents with unrelated
content Scribd suggests to you:
constant, but a peculiar feature about them is that some may be very
bad for louping-ill one year, and others bad another year. Of two
adjoining farms, one may be badly attacked and the other mildly,
while in the following year the conditions may be reversed. Districts
may present the same peculiarities. Thus, though the disease is
essentially endemic, it is not absolutely constant in its recurrence.
There seem to be certain circumstances capable of favouring or
retarding it.
Lesio
ns. The
chief
lesions
are
localised
in the
membra
nes of
the
brain
and
spinal
cord,
which
are
congeste
d or
inflame
d, and
contain
an
Fig. 198.—Larva of the grass tick. increase
d
Length, ¹⁄₄₀th of 1 inch. amount
of
cerebro-
spinal fluid or a jelly-like, sometimes blood-stained exudation.
Softening and hardening of the spinal cord have both been observed.
Inflammation of the pleura and pericardium, with fluid or jelly-like
exudation, are common; lobar congestion of the lungs, endocarditis,
gastritis, and
enteritis have all
been described;
some observers
have mentioned
congestion of the
kidneys and liver
and swelling of
the spleen.
Lesions of the
nerve-centres are
the most
constant and
reliable.
Etiology.
Depressing and
weakening
influences of all
kinds have been
blamed for
producing the
disease, but the Fig. 199.—Pupa of the grass tick.
general
consensus of Length, ¹⁄₁₈th of 1 inch.
opinion points in
the direction of
infection with microorganisms carried and introduced into the
sheep’s system by the common sheep tick or “grass tick” (Ixodes
redurius). The following remarks on, and illustrations of, this
parasite are from an article by Mr. Wheeler, of Alnwick
(Veterinarian, Vol. LXXIII., No. 867, p. 141).
Life History of the Grass Tick. Sheep ticks (which must not be
confused with the sheep-ked, or keb, a wingless six-legged fly,
universal on sheep everywhere) are allied to the spiders. They pass
through four stages of existence: the egg—the six-legged larva—the
eight-legged pupa—and, finally, the eight-legged adult male or
female.
 In each of
the three
stages of
larva, pupa,
and adult
female, all
species of
ticks attack
some “host”
or animal,
either beast,
bird, or
reptile, to
which they
attach
themselves
by the
“rostrum” or
beak, and
become
greatly
distended by
Fig. 200.—Adult male of the grass tick. Length, ⅑th suction of
of 1 inch. the host’s
blood. When
replete they
fall to the ground—if a larva or pupa, in order to undergo its
metamorphosis to the next stage of its existence, and afterwards seek
a fresh host; if an adult female, to lay its eggs amongst herbage. The
adult male is not capable of distension by suction, though it equally
attaches itself to a host.
After undergoing metamorphoses, grass ticks, with the exception
of males, are light in colour, soft and lethargic, and remain concealed
for some time while recovering strength before seeking a fresh host.
Professor Neumann alludes to the fact that a fresh host is sought
by ticks three several times during their existence.
The Larva. When first hatched out from the eggs, which are
supposed to be laid at the roots of coarse herbage, the young ticks are
white and soft, but
soon gain strength.
Provided the
weather is
favourable, they
climb up the stems,
and, holding by their
two posterior pairs
of legs, await the
passing of a host,
employing their two
front legs as insects
use their antennæ.
In this, as in other
“free living” stages of
their existence, the
young larvæ show
great activity,
attaching themselves
and clinging
tenaciously to any
moving object. They
appear to be more Fig. 201.—Adult female. Length, ⅐th of 1
numerous on the inch.
rank rushes growing
in damp, undrained
places.
On finding a host, larvæ attach themselves by the rostrum, and
remain there for about two days, by which time they are distended,
black and globular. At this time they are easily detached from the
host, and have lost their activity and clinging habits.
The Pupa. The possession of eight legs distinguishes the pupa
easily from the larva. The extra pair are placed behind the others.
After the metamorphosis, the pupa takes up its position on the stalks
of herbage, just as the larva had done, for another chance of
attachment to a host. But whereas adult grass ticks seem to confine
themselves mostly to sheep, cattle, and deer, the larvæ and pupæ
attach themselves very readily to various hosts, such as horses, dogs,
and even
human
beings. After
about four
days the
pupa is again
replete with
blood, black
and opaque,
and again
drops to the
ground to
undergo its
second and
final change.
Adults.
On reaching
the adult age,
both males
and females
again wait on
herbage for a
passing host. Fig. 202.—Partially distended female. The dotted
At this time, white line represents the size of the tick before
as well as distension.
after
distension of the female on the host, an action which appears to be
sexual intercourse freely takes place, even in confinement. On the
host the females gradually distend (Fig. 202), and in the course of so
doing vary much in colour and appearance. When fully replete, the
female Ixodes reduvius becomes globular and black. One taken in
this condition on April 15th commenced to lay on May 12th, and a
few others taken at the same time commenced shortly afterwards.
Grass ticks never remain on the host to undergo metamorphosis or
to lay eggs. They must therefore during their cycle of existence
contrive to find a fresh host no fewer than three times.
In an article published in the Transactions of the Highland and Ag.
Soc. for 1902 Mr. Wheeler draws attention to the close points of
resemblance between louping-ill, Texas fever, tsetse fly disease,
surra, heart-water, yellow fever, and malaria.
In the article previously referred to he summarises his conclusions
as follows:—
One species only of tick, Ixodes reduvius, commonly known as the
grass tick, has been found to carry the louping-ill bacillus to the
sheep. It is easily recognised by the red body of the young females,
the legs, shield, etc., being dark brown.
It lays its eggs, and undergoes its metamorphoses, in coarse
herbage, and after each change seeks a fresh “host” on which to
distend itself to a large size by suction of blood.
In all stages
grass ticks
abstain from all
food except
when on a host,
and they are
endowed with
extraordinary
powers of fasting
until a host is
found.
Ticks soon die
of drought
where there is
no good
harbourage
among rank
vegetation.
Judging from
analogy, it is
probable—
Fig. 203.—Female, under size. That the
bacillus can only
be obtained
from a diseased sheep, and inserted by the tick into another sheep.
 That
ticks
convey
the
bacillus
through
their
eggs to
their
offspring
, as well
as retain
it
through
their
metamor
phoses.
That
there is
no
danger
in
removin Fig. 204.—Headless female.
g sheep
from foul ground to cultivated lowlands, but that the disease is easily
imported from one hill farm to another.
Strong and fat animals are nearly as susceptible to attack as weakly
ones.
If the land is once free of disease, it can only be re-imported by
diseased sheep, or ticks taken from them.

SUGGESTED MEASURES FOR PREVENTION.

Burning and cutting of long grasses, bracken, rushes, etc.

Salt and sulphur given to the sheep.
Inoculation.
 Removal of all diseased sheep to a separate inclosure, where hand-
picking and dipping are carefully attended to, the pasture is kept
short, and damp places are drained. The sheep to be confined to this
inclosure so long as the tick season lasts.
Immediate slaughter and burial of all affected sheep.

BRAXY.

[The following is a very condensed account of a paper published by

C. O. Jensen on the above disease. It first appeared in English in the
Veterinarian, Vol. LXIX., No. 825, p. 621, along with the original
illustrations.]
The name Braxy is applied to a disease in some respects
resembling anthrax, which appears as an epizootic, and is best
known in Iceland, the Faroe Islands, and parts of Norway, though it
also occurs in Scotland and Cornwall. Krabbe describes the disease
as infectious, very acute in its course, and as proving fatal within a
few hours of the appearance of certain characteristic swellings about
the posterior parts of the body. Post-mortem reveals extensive dark
purplish staining of the abomasum and distension of the digestive
canal with gas, while decomposition of the cadaver occurs with
excessive rapidity, the liver and kidneys undergoing softening, the
skin assuming a bluish tint, the wool becoming loose, and the entire
carcase giving off a most offensive stench. Krabbe states that the
disease was regarded as a form of anthrax—a view, however, in
which he does not coincide. Somewhat later Messrs. J. Sigurosson, S.
Jönsson, and Einarsson, all natives of Iceland, and the Norwegian
State Veterinary Surgeon, Ivar Nielsen, carefully described the
disease, throwing considerable light both on the conditions in which
it appears and on its etiology.
According to them, braxy is an acute, or even exceedingly acute,
infectious disorder, which begins as a hæmorrhagic inflammation of
the mucous membrane of the abomasum, is accompanied by
excessive development of gas in the digestive canal, especially in the
stomachs, and proves fatal in some cases by a kind of general
infection, in others by a specific intoxication, or by dyspnœa due to
tympanites.
 Braxy commits its chief ravages during the winter months:
appearing first in autumn, the cases increase as winter approaches,
to diminish again in spring; in summer they are exceedingly rare.
This fact explains why the disease was so long regarded as due to
climatic influences. Even at the present day, when it is known to be
due to a specific organism, the action of temperature, etc., must still
be regarded as probably playing an important part in infection. The
disease is said not to occur in mild weather; but whether or not this
be true, every one is agreed that it is principally seen during frost,
especially when frost is unaccompanied by snow.
From experience gained both in Iceland and Norway, the disease
appears to be often localised in certain districts and fields—a fact
largely accounted for when we learn that up to the present little or no
attempt has been made to prevent the spread of infection from the
dead bodies.
Braxy chiefly attacks young animals, and is rare in those over three
years of age. Hjaltelin estimates the number of deaths in a single
district during the years 1849–1854 at approximately 6,000, made
up as follows:—

Yearling lambs 2,440

Two-year sheep 2,460
Three-year sheep 1,020
Animals older than three years 80

The younger animals suffer most, and in Norway Nielsen directs

attention to the heavy fatalities amongst lambs.
Symptoms. The sheep suddenly appears ill, is dull, lies about,
and cannot be induced to rise; all movement seems to give pain, and
from time to time the animal groans; the posterior parts of the body
become swollen, and a little froth often escapes from the mouth. The
pulse varies between thirty and thirty-five per minute, and is often
imperceptible in the extremities; the temperature may rise to 105° or
even 108° Fahr. This condition may last some hours, and always
ends with the animal’s death; sheep, which overnight had shown no
signs of illness, are often found dead in the morning. The incubation
period is from forty-eight to sixty hours, but ordinary cases seldom
live longer than from five to eight hours after the symptoms declare
themselves.
The striking post-mortem appearances, especially the
hæmorrhagic inflammation of the abomasum, were early the subject
of remark. This appearance is very characteristic.
If the animals are slaughtered, the most important change is found
to be a purplish, dark, somewhat swollen patch in the abomasum;
during the course of the disease this increases in size, and if the
animal should be allowed to die of braxy the entire abomasum shows
hæmorrhagic or sero-hæmorrhagic infiltration; the abomasum and
the first part of the small intestine usually contain no food, but may
often show a certain amount of bloody fluid. This hæmorrhagic
inflammation may extend in a forward direction, implicating the
other stomachs, or backward, invading the small or both small and
large intestines. The other parts of the intestinal canal are congested.
The pleural and peritoneal cavities contain a little serous fluid. The
blood is dark in colour, but may be clotted; the spleen is at times
somewhat swollen, at others normal. The liver is usually light-
coloured, soft, and degenerated; occasionally this degenerative
process is extremely marked, but due allowance should always be
made for post-mortem change. The kidneys may appear
degenerated; in many cases they are enlarged and soft, or almost
fluid in consistence. The carcase decomposes very rapidly; within a
short time of death the belly is distended with gas, the rectum
protrudes at the anus; the skin assumes a bluish colour in places, and
the wool falls out; sometimes the skin bursts, revealing the presence
in the subcutaneous tissue of a sero-hæmorrhagic fluid.
 Fig. 205.—The shaded areas of the above map indicate the
distribution of braxy.

Braxy is, then, a primary violent hæmorrhagic inflammation of the

abomasum, with or without secondary general infection.
From careful study it seems quite certain that the Scottish “braxy”
is identical with the Norwegian and Icelandic “bradsot”; it appears at
the same season, and is intimately connected with climatic
influences; it runs its course so rapidly that animals left healthy at
night are found dead in the morning; and the pathological anatomy
of braxy is the same as that of “bradsot.”
To Ivar Nielsen, of Bergen, must be ascribed the honour of
elucidating the etiology of braxy. During the course of investigations,
published in 1888, he found, partly in the local lesions of the
intestinal track, partly in the capillaries of the internal organs, a
special bacillus, easy to distinguish from that of anthrax, of which he
gives the following description:
 “The bacilli (B. gastromycocis-ovis) are oval, of a length varying
from 2 to 6 micromillimètres, and a thickness of one
micromillimètre. They are often in pairs, arranged in a straight line
or meeting at an angle; in the former case, and especially if deeply
stained, the pair may present the appearance of a single bacillus.
Occasionally they form long chains. Near the centre of the bacillus,
but not always centrally placed, may often be found a zone
measuring more than half the total length of the bacillus, and
exhibiting little or no colouration. It appears as though the stained
portions gradually contracted, finally forming two deeply coloured
masses at the poles of the lemon-shaped bacillus, which then
somewhat resembles the bacillus of rabbit septicæmia, except that
the unstained part of the braxy bacillus is larger and more rounded,
appearing to be bulged out laterally. In dry preparations the bacillus
is easily recognised on account of the highly refractile character of
the colourless portion; but in sections careful search is often
required, especially if the section be somewhat thick. Whether the
colourless portion represents a spore cannot at present be said,
though such appears probable. The bacillus is always found in the
mucous membrane of the abomasum, and especially in the
submucous and subserous connective tissue. In the other organs the
bacillus may be present in considerable numbers, or, on the other
hand, may be impossible to detect.”
The same bacillus has been found in the tissues of affected sheep
both in Norway and in Iceland; the bacillus, when subcutaneously
injected, produces a violent hæmorrhagic inflammation of the same
character as one finds in the abomasum in cases of spontaneous
braxy, and the local changes at the point of inoculation may, just as
in spontaneous braxy, be accompanied by a general infection with
degeneration of different organs, and with softening of the kidney
substance.
The bacillus of braxy is anaërobic. In cultures it develops
considerable quantities of gas, just as it does when inoculated into
the tissues. It is closely related to the bacillus of symptomatic
anthrax, which it somewhat resembles in general appearance, and of
which it reminds one by its ability to produce hæmorrhagic
inflammation in the muscular tissues. It is distinguished from the
last named, however, by being pathogenic to swine, mice, pigeons,
and poultry, which are not killed by the bacillus of symptomatic
anthrax.
The bacilli of braxy, malignant œdema, symptomatic anthrax,
together with Ivar Nielsen’s shortly described bacillus of whale’s
septicæmia, and Thoma’s bacillus of malignant emphysema (found
in extensive subcutaneous inflammation and emphysema in man),
and certain others less well known, form a group of closely allied
bacilli resembling one another in form, in being anaërobic, and in
producing a sero-hæmorrhagic inflammation and emphysema, but
differing in the manner of producing their effects.
Experience and analogy both seem to indicate that young animals
occasionally suffer from mild attacks of braxy from which they
recover. Such animals afterwards exhibit a well-marked immunity
against the disease.
Ivar Nielsen attempted to vaccinate against braxy by a method
resembling that used in black-quarter. He dried the diseased kidney
tissue, and injected subcutaneously small quantities of the material
thus obtained suspended in water. A slight local inflammation
followed, which appeared to protect against later “spontaneous”
infection. He has used this method in his own district, and states that
it is also practised to some extent in Iceland. As far as one can judge
—and of course a just opinion is very difficult to form—these
inoculations appear of value.
The result of experiment, considered in conjunction with the good
results of inoculation for black-quarter, would seem to indicate that
Nielsen’s method of vaccination against braxy may yet prove of the
greatest possible value, although the method will doubtless require
modification in its details.
These modifications Jensen enumerates at some length.
(Mr. Dollar has been informed that Professor Hamilton and Dr.
McCall have been engaged in an investigation regarding the
possibility of conferring immunity against braxy, and that a
Government report will be issued on the subject. Up to the present
time however—April, 1905—he has not been able to obtain this
report or any advance proof sheets of it.)

BILHARZIOSIS IN CATTLE AND SHEEP.

 This disease is caused by the bovine blood fluke (Schistosoma
bovis) of cattle and sheep. Synonyms: Bilharzia bovis; Bilharzia
crassa; Gynæcophorus crassus; Gynæcophorus bovis; Bilharzia
hæmatobia crassa; Schistosomum bovis.
Geographical Distribution. Egypt, Italy, Sicily, India (?).
This parasite was discovered by Sonsino (1876) in Egypt in the
portal veins of the ox, and later he found it in sheep, while Grassi and
Rovelli afterwards found it in about 75 per cent. of the sheep
slaughtered at Catania, Sicily.
Source of Infection. Clinical observation and analogy point to
unfiltered drinking water as the source of infection.
Position of the Parasite. The worms are found in the veins of
the abdomen, the vena porta, vena linealis, vena renalis, and the
venous plexus of the bladder and of the rectum.
Symptoms. The young parasites appear to do no injury; in fact,
even the adult worms seem to be inoffensive in themselves. The eggs,
on the other hand, armed with a sharp point, are the exciting cause
of the disease. The position of the parasite in the venous system, and
the consequent location of the agglomeration of eggs, determine the
particular symptoms. Either the genito-urinary system is attacked, in
which case hæmaturia is one of the first symptoms, or the large
intestine is attacked and blood is noticed in the fæces.
If the parasites are lodged in the venous plexus of the genito-
urinary system, the chief symptoms are: hæmaturia, pains in the
lumbar region, the left iliac fossa, the thigh, or in the vulva, which
may be spontaneous or may accompany micturition; cystitis, vesical
calculus, urinary fistulæ, vaginal verminous tumours, nephritis.
The eggs accumulate in the capillaries, which they rupture; they
traverse the mucosa and fall into the bladder, thus causing more or
less hæmorrhage; in this way the hæmaturia is established, which is
often the initial symptom. At first the urine is quite bloody, but it
gradually becomes clearer, and it is only at the end of micturition
that muco-purulent flakes are expelled, in which numerous eggs and
even embryos are found; the urine contains also epithelial cells, more
or less pus, eggs, and occasionally embryos. On micturition sharp
pains are felt at the base of the penis or at the gland, possibly due to
the passage of eggs. The passage of eggs through the walls of the
 bladder gives rise to
cystitis; blood becomes
more abundant in the
urine after fatigue or
coitus; clots may form and
cause retention of urine;
chronic urethritis may
develop, evidently due to
the presence of the eggs.
In Egypt 80 per cent. of
the cases of vesical
calculus in man coincide
with bilharziosis; the
formation of the calculi
evidently results from the
presence of the eggs, for
the central nodule always
contains one or more of
these structures. Urinary
fistulæ, opening on the
perineum, more rarely
into the rectum,
occasionally form. The
mucosa of the vagina, also
of the uterus and bladder,
Fig. 206.—The bovine blood fluke
becomes impregnated
(Schistosoma bovis), male and female.
with calcareous salts.
× 9. (After Leuckart, 1894, p. 467, Fig.
Nephritis develops in
204 A.)
grave cases.
If the parasites lodge in
the veins of the rectum the lesions caused are analogous to those
described for the genito-urinary tract.
The heart, lungs, and liver generally remain normal.
Pathology. The bladder is reduced in size, while its wall is greatly
thickened, due chiefly to hypertrophy of the muscularis; the mucosa
is also thickened, and at certain points it is indurated by uric or
calcareous deposits, but the principal lesion consists in ulcerations
covered with sanious pus. Lesions analogous to those of the bladder
are also
observed
in the
lower
third of
the
ureters,
and may
extend as
high as
the
kidney;
the ureter
is
enlarged
and
tortuous;
the
mucosa
irregular;
its lumen
may
remain Fig. 207.—Cross-section of bovine blood fluke
nearly (Schistosoma bovis), showing the position of the female
normal in in the gynæcophoric canal. × 200. (After Leuckart, 1894,
size, but p. 472, Fig. 209.)
its wall
becomes
very thick: the flow of urine may be obstructed; in short, a veritable
hydro-nephrosis obtains, which results in atrophic lesions of the
kidney, and may finally end fatally.
The mesenteric lymphatic glands may hypertrophy, their
substance becoming tumefied, presenting small hæmorrhagic
centres, and containing eggs. The liver may contain eggs and become
somewhat cirrhotic; the eggs accumulate in the branches of the
portal veins, or after piercing the walls they lie in the hepatic
parenchyma. The lungs may also contain eggs.
 Diagnosis. The diagnosis
may easily be made by a
microscopic examination of
the urine to determine the
presence of the egg.
Prognosis, etc. The
severity of the disease varies
directly with the number of
parasites (and hence the
number of eggs) in the body.
Fortunately, in the majority
of cases, the number of
parasites is small, though it
may increase from repeated
infections to 500 or more. In
cases of comparatively light
infection the disease is
reduced to a slight chronic
cystitis, with now and then
exacerbations, in course of
which a slight amount of
blood and pus is passed in
Fig. 208.—Eggs of bovine blood fluke the urine. The disease may
(Schistosoma bovis), showing the last for years without
peculiar process on the end. a, b, apparent increase. In the
Layers of the oviduct; c, eggs in the most severe cases death may
oviduct × 180; x, eggs deformed by occur from various causes,
pressure; y, spinous process on end of rupture of the bladder,
egg × 700. (After Sonsino.) ascending pyelo-nephritis,
uræmia, albuminuria; the
patient may die in marasmus, being exhausted by the dysentery or
the anæmia.
Bilharziosis is accordingly not such a fatal disease as has
sometimes been supposed.

HEAT STROKE—OVER-EXERTION.
 In oxen and sheep heat stroke is rare as a primary accident, but it
is frequently produced by over-exertion resulting from the combined
action of the sun’s rays, heat, and fatigue due to work or travelling.
It is commonest during the hottest months of the year in oxen
doing hard work or in flocks which have been travelled considerable
distances. It may also be seen during cooler seasons as the result of
exceptional fatigue.
The disease results from a general intoxication which reacts most
markedly on the cerebro-spinal centres. It is in fact a complex
intoxication resulting from failure of the natural excretory organs to
perform their function completely, and from excessive central heat
acting on the nervous centres.
Fat animals out of condition are more readily attacked than
working animals or sheep reared in the open air.
The symptoms are very characteristic. Oxen when attacked first
of all show extremely rapid respiration and dyspnœa, announcing
progressive asphyxia. They move with the nostrils dilated, the eyes
prominent and injected, the mouth open and the tongue lolling out.
Then all of a sudden they come to a stop beside a wall, or, if at
liberty, in a ditch, and refuse to move. They may die rapidly with
symptoms of asphyxia if they are forced to move until completely
exhausted. In others, after a rest of several hours, the breathing
becomes slower, the anxiety less and normal conditions return.
In sheep the same general signs may be seen: panting respiration,
cyanosed mucous membranes and extreme anxiety, while death
follows rapidly in the same way, with symptoms of asphyxia.
The diagnosis is extremely easy. The prognosis is grave.
Treatment consists in prompt and free bleeding to prevent
pulmonary congestion. The animals should be rested in a shady,
sheltered spot. They should have cool drinks and be sprinkled over
the head, neck, or entire surface of the body with cold water.
To prevent such attacks, fat animals should not be moved for long
distances, or during the hottest hours of the day, while difficult and
prolonged exertion should be avoided.
 CHAPTER VI.
DISEASES OF THE LYMPHATIC SYSTEM.

Diseases of the lymphatics are numerous, highly important, and

still imperfectly understood. They follow various accidents, local
inflammations, certain specific diseases, such as tuberculosis, and
may occur in an isolated form without involving any other part of the
body.

Fig. 209.—Superficial lymphatic glands of the head and neck. P, parotid gland;
Gl.SM, submaxillary gland; GaSG, subglossal gland; GaPPA, preparotid gland;
GaSA, subatloid gland; GaPS, prescapular gland; GaPPE, prepectoral gland; J,
jugular; 1re C, first rib.

Inflammation, usually of infectious origin, may attack lymphatic

vessels (lymphangitis) or lymphatic glands (adenitis), giving rise
either to simple lymphangitis, suppurative lymphangitis, or again to
simple or suppurative adenitis.
It is unnecessary to emphasise this point in general surgical
pathology, for it is identical with that which is observed in other
domestic animals, but in order properly to detect the glandular
symptoms in certain diseases peculiar to the lymphatic apparatus,
and in certain specific diseases, such as tuberculosis, farcy of the ox,
etc., it is necessary to understand thoroughly the topography of the
lymphatic system.
Topography of the lymphatic glandular apparatus:
Examination. The lymphatic glands are in some cases superficial,
in others deep seated, and are arranged symmetrically on either side
of the body.
Welcome to our website – the ideal destination for book lovers and
knowledge seekers. With a mission to inspire endlessly, we offer a
vast collection of books, ranging from classic literary works to
specialized publications, self-development books, and children's
literature. Each book is a new journey of discovery, expanding
knowledge and enriching the soul of the reade

Our website is not just a platform for buying books, but a bridge
connecting readers to the timeless values of culture and wisdom. With
an elegant, user-friendly interface and an intelligent search system,
we are committed to providing a quick and convenient shopping
experience. Additionally, our special promotions and home delivery
services ensure that you save time and fully enjoy the joy of reading.

Let us accompany you on the journey of exploring knowledge and

personal growth!

ebooknice.com