SOAP provides a simple and lightweight method for exchanging structured data. It
defines the message package, offers encoding guidelines for data used in
applications connected by these messages, and provides rules for representing
remote procedure calls (RPCs), a type of online interaction in a distributed
environment. The authors (from Microsoft Corp., IBM and its Lotus Development
subsidiary, DevelopMentor, and Userland Software) submitted version 1.1 of SOAP
to the W3C as a Note in May 2000.

SOAP’s importance extends beyond its definition of an XML-based message
protocol. Several other e-business specifications based on XML — most notably
BizTalk and Universal Description, Discovery and Integration (UDDI) — use SOAP
for its messaging functions.

SOAP messages are XML documents defined in a mandatory SOAP envelope. Within the
envelope are a SOAP header and body. SOAP messages must have a body, but the
header is not required in all instances. The XML namespace, http://schemas.xmlsoap.org/soap/envelope/
is used for the envelope. Namespaces allow access of multiple document type
definitions (DTDs) or schemas in an XML document by providing a unique prefix
that prevents duplication of element or attribute names.

The SOAP envelope serves as the first element in the document and thus
identifies it as a SOAP message. The SOAP body contains the information
transmitted to the receiver. Each message must have a body, so there cannot be
an empty SOAP message. If the message has a SOAP header, it appears as the first
child element in the envelope, and before the body.

The SOAP header allows the sender to add management or control information in
the message, important for routing, security, or proper handling by the
recipient. This element has very few rules of its own, but relies on XML
namespaces identified by the sender for its semantics.
Reversing an Earlier Decision

Including SOAP in the messaging specifications reversed an earlier decision by
the ebXML messaging project team to develop its own message structure. The team
had originally proposed an enveloping format combining Multipurpose Internet
Mail Extensions (MIME) for the overall message envelope as well as header and
body containers. In the original plan, the header container written in MIME
would have XML data providing identification and description of the message.

At the August 2000 ebXML meeting in San Jose, California, Rik Drummond of The
Drummond Group and chair of the ebXML Transport-Routing-Packaging (messaging)
project team, announced the results of its review of SOAP. The review predicted
that with the high production volumes often encountered in e-business, SOAP’s
all-XML messaging could overwhelm most XML validators. On the other hand, the
combination of MIME and XML headers proposed for ebXML messaging would likely
provide more robust support. (See ebXML: Assembling the Rubik’s Cube, XML.Com,
16 August 2000).

SOAP in its original form also did not support non-XML attachments. Some
e-business messages, however, will carry non-XML binary files, such as digitized
engineering drawings or patient X-rays. The messaging project team recommended
the MIME multipart/related media type for the overall ebXML envelope in part for
its ability to attach these binary files.

At the Data Interchange Standards Association (DISA) e-business conference on 8
March, Drummond explained some of the reasons for this change in outlook about
SOAP, and he gave a high-level view of how the pieces would fit together. He
noted that new enhancements to SOAP, including the addition of MIME support,
helped meet ebXML requirements, specifically the SOAP With Attachments
specification. This document, submitted to the W3C as a Note in December 2000,
defines a SOAP package that combines the SOAP 1.1 message with a MIME envelope
to include direct attachments or references.

This combination of SOAP messaging in XML and MIME allowed the ebXML messaging
team to specify an outside MIME envelope and subsidiary MIME parts for header
and body containers. At the DISA conference, Drummond illustrated how it would
work.

The ebXML header container consists of a SOAP message with a SOAP header and
SOAP body. The SOAP header includes the traditional functions found in business
message headers, such as identification of the parties to the transaction
(sender, receiver, copies).

The SOAP body — still within the overall message header container — carries
data cataloging the message contents, which is called a manifest in ebXML
parlance.
The ebXML body container carries the payload that can be in XML or any other
digitized format.
Intellectual property issues

EbXML faced more than just technical issues with SOAP. A key property of ebXML
often cited by its supporters is its openness, both in its development process
and its promise to make its documents freely available. For example, the ebXML
requirements specification issued in May 2000 includes the following under its
general business requirements:

An open development process with no barriers to entry
Open, readily accessible, perpetually free technical specifications and
standards

SOAP, on the other hand, is a product of a small group of vendors.
Representatives of four companies developed SOAP, and while other companies have
endorsed it, SOAP was not the product of an open consensus-based process
required for accredited standards.

Licensing restrictions imposed by the original developers also opened issues
that appear to conflict with these requirements. On 8 March, Microsoft and IBM
issued statements clarifying the intellectual property issues on SOAP 1.1 and
SOAP With Attachments that ebXML relayed in a press announcement. Microsoft said
it will grant a license to the intellectual property rights for these
specifications but only for the purpose of compliance with the specifications.
The company also issued a disclaimer that users accepted the specifications
as-is and would not be subject to actions resulting from consequences of their
use. IBM issued a shorter statement granting a non-exclusive license to its
intellectual property in SOAP upon written request.
End game strategy for ebXML emerges

The technical architecture specifications approved by the ebXML plenary at its
mid-February meeting in Vancouver, Canada, provide a technical map for the other
ebXML project teams in developing the details of the technology. The document
also provides a look ahead into the end game for the initiative.

Part of that strategy includes the critical ebXML registry specifications.
Companies will have most of their early encounters with ebXML through the
registries, as companies download business processes, list their capabilities to
conduct e-business, and search for potential trading partners. At the same time
as the release of the messaging specifications, ebXML also released for review
two draft specifications for registries: one for the registry services and the
other for the registry information model. The registry services document spells
out the functions and operations of ebXML registries, while the information
model details how registries organize and index the data they represent.

Also on 28 March ebXML released for review the draft trading partner profile and
agreement specifications. The ebXML specifications carve out specific
technically-oriented functions for trading partner information stored in
registries (profiles) and the rules of the road for conducting e-business
(agreements). As a result, ebXML uses the terms collaboration-protocol profiles
and collaboration-protocol agreements to distinguish them from the more
comprehensive trading partner profiles and agreements that contain much more
than technical details.

EbXML expects to finish its technical specifications in May 2000 at its last
meeting in Vienna, Austria. At that time, the participants plan to take up the
business process and core components specifications, the last two pieces of the
technology still in development.

Reactions to the announcement of ebXML integrating SOAP into its specifications
drew general applause from industry watchers, with headlines on the major IT
news sites and even a story on the Reuters news wire. The episode did serve as a
reminder that competing e-business standards need to consolidate if they hope to
succeed, even if it means a certain loss of innocence in making those
accommodations.

My first "official" act in this next phase of SOAP’s development is to take a
few minutes to retrace the steps that got us here. Hence this article.

In the Beginning: SOAP 98
When SOAP started in early 1998, there was no schema language or type system for
XML (in fact, XML 1.0 had just become a full Recommendation that quarter). If
you look at earlier versions of the SOAP spec (including XML-RPC, which was
subsetted from the 1998 SOAP spec), most of the focus was on defining a type
system. The original type system of SOAP (and XML-RPC) had a handful of
primitive types, composites that are accessed by name (a.k.a. structs) and
composites accessed by position (a.k.a. arrays). Once we had these
representational types in place, we modeled behavioral types by defining
operations/methods in terms of pairs of structs and, at least on the
DevelopMentor and Microsoft sides, aggregated these operations into interfaces.
Hence the RPC flavor that people associate with SOAP.

Was SOAP the first attempt to add a behavioral type system to XML? Not at all. I
recall scanning the landscape at the time. The existing proposals either assumed
a COM type system underneath (unacceptable, since even back in 1998 we knew COM
wasn’t the ultimate type system) or were very EDI-like, which would alienate
parts of the development community. For that reason, we looked at the existing
serialization formats (ASN.1 BER, NDR, XDR, CDR, JRMP) and RPC protocols (GIOP/IIOP,
DCE/DCOM, RMI, ONC) and tried to hit the sweet spot that would satisfy the 80%
case elegantly but could be bent to adapt to the remaining 20% case.

So why didn’t we ship SOAP back in 1998? That one’s easy: Microsoft politics.

The original contributors to SOAP within MS worked on the COM/MTS team. At the
same time, the XML group within MS was working on XML-Data, which became one of
the many seeds for the XML Schema language we know today. As is often the case
in large companies, the two groups within MS didn’t see eye to eye, so public
support for SOAP got shelved within MS for some period of time. (As a side note,
I was one of those people who didn’t get XML-Data when I first encountered it,
and I have publicly apologized to Andrew Layman at least twice for being so
dense.)

Unwilling to let the slow process of getting MS to act on SOAP beyond a press
release, Dave Winer went out on his own and shipped the XML-RPC specification
based on subsetting the original SOAP type system. I spent the rest of the year
working on Java metadata grunge, including among other things a projection of
Java class files onto XML.

SOAP Phase 2: 1999-2000

By the time a SOAP specification finally shipped using the name "SOAP" (4Q1999),
the W3C XML Schema language was by no means done, but it certainly had
progressed to a point where it became obvious to most of the SOAP authors that
we needed to leverage and integrate the work of the Schema Working Group as much
as possible. Their primitive types were a superset of what we needed for SOAP.
Their composite type system was mostly a superset of what we needed for SOAP. It
would have been folly to ignore their work.

Ideally SOAP would have taken the representational type system of XML Schemas
verbatim and simply added the notion of behavioral types and operations/methods.
Unfortunately, XML Schemas lacked (and still lacks) support for synthetic types
such as typed references and arrays. While you can define things that look like
typed references and arrays in the schema language, these constructs are not
really native to XML Schemas. Worse, you would need to predefine these reference
and array types, which makes it really difficult to isomorphically move back and
forth between say a Java class and an XML Schema complex type. For that reason,
SOAP needed to augment the type system with the soap:reference and soap:Array
types. It is interesting to note that the Schemas Working Group tried to tackle
the typed reference issue; but, unfortunately, it couldn’t converge on a
solution that would support typed references as they appear in most programmatic
type systems.

Most of what the 4Q1999 SOAP specifications did was simply illustrate how to
model typed references and arrays in the W3C XML Schema type system. Period. We
also had a model for adding optional and mandatory protocol headers (like
CORBA’s service contexts and DCOM’s ORPCTHIS/THAT), but that was it. Frankly,
had the schema specification been a full REC in 4Q1999, the SOAP specification
would have at most 3-4 pages. However, the XML Schema specification was changing
radically with each successive Working Draft, so those of us working on SOAP had
to deliberately insulate ourselves from the churn that was W3C XML Schema during
1999 and 2000 in order to make any progress whatsoever.

To me, the biggest technical issue that faced SOAP in 1999 and 2000 was the lack
of metadata. DevelopMentor tried to introduce a simple metadata format ( CDL)
that was isomorphic with the XML Schema type system, yet didn’t tie us to the
rather fluid schema language. Dave Winer totally balked at the idea of metadata
, indicating that human-readable descriptions were all that was needed.
Certainly folks like Eric Raymond seem to agree with him. The reason we
abandoned CDL, however, was a discussion with Gopal Kakivaya of Microsoft, who
convinced us that what we needed could be achieved by annotating XML Schemas
with additional SOAP-specific hints that were allowed (and in fact anticipated)
by the Schema specification. At this point, DevelopMentor joined the Schemas WG
and most of our effort internally moved towards XML Schema support. We use XML
Schema a lot around DM, having shipped an XSD compiler for C++ that we use
internally.

The biggest non-technical issue that faced SOAP in 1999 and 2000 was the hideous
nature of vendor wars. The FUD that flew around the trade press and vendor web
sites was downright embarrassing. I recently ran across a Sun Reality Check that
made me ill. In particular, the following quote blew me away:

SOAP has changed a lot. It started to become interesting to us when IBM made
additions to the mediocre specification that Microsoft initially championed
(you’re right, we thought that specification was a bad idea).

If SOAP/1.0 (the last pre-IBM version) was a bad idea, then so was SOAP/1.1 (the
first post-IBM version, which was submitted to the W3C). There were no major
improvements to SOAP from 1.0 to 1.1. The specification was reorganized to make
the modular design of SOAP more apparent. However, the few minor technical
changes we made were arguably a step backward (in fact, I believe to date there
are no SOAP implementations that do anything meaningful with the one new
feature, SOAPActor).
The Post-SOAP Era: 2001 and beyond

So where are we now? Tough question. Here are some observations about the
current state of play.

The XML Schema specification is stable and now a Proposed Recommendation.
To me, this is the most important advance for people who care about XML
protocols and messaging in general and SOAP in particular. The fact that no
major changes can be made before advancing to a full W3C recommendation means
that the industry at large knows what they are dealing with when it comes to
applying types to XML. I have stated before, and I still stand by my belief,
that without XML Schemas, XML is a balkanized standard and its utility for
software, component, or service integration is fairly minor. The Schema
specification does most of the heavy lifting for SOAP, and it kills me that we
can’t do a SOAP/1.2 to address the new schema language. Which brings me to my
next observation.

The W3C now has a XML Protocol Working Group.

SOAP is now where it belongs. Until we got W3C buy-in, vendors were skittish
given the nature of the industry. Now that SOAP has been subsumed into the XML
Protocol work, the big vendors have (for the most part) stopped arguing about
SOAP and we have a fairly open process for beating the protocol into shape. In
my opinion, one of the smartest things the WG did was to immediately define
their relationship to the XML Schema type system.

We are somewhat closer to having a standardized metadata format for SOAP.
While far from perfect, WSDL is as close as we’ve ever come to having a workable
metadata standard that more than three people can agree on for longer than a
week at a time. Is WSDL perfect? Not by a long shot. Is it workable? For the
most part, yes. Does SOAP/XML Messaging make sense without something like WSDL?
No way. My own criticisms of WSDL relate to WSDL’s current form having a
somewhat schizophrenic relationship to XML Schema. (In fact, there are several
ways in which WSDL and XML Schema are completely incompatible.) Despite my
criticisms, portions of WSDL are more than workable, albeit overly verbose and
indirect, for every SOAP scenario or application I have dealt with in the past 3
years. Hopefully the XML Protocol Activity will focus on finishing the WSDL
specification and give the world at a reasonable way of describing, validating,
and automating XML-based services.

For the most part, people have stopped arguing about SOAP

SOAP is what most people would consider a moderate success. The ideas of SOAP
have been embraced by pretty much everyone at this point. The vendors are
starting to support SOAP to one degree or another. There are even (unconfirmed)
reports of interoperable implementations, but frankly, without interoperable
metadata, I am not convinced wire-level interoperability is all that important.
It looks like almost everyone will support WSDL until the W3C comes down with
something better, so perhaps by the end of 3Q2001 we’ll start to see really
meaningful interoperability.
Epilogue

SOAP’s original intent was fairly modest: to codify how to send transient XML
documents to trigger operations or responses on remote hosts. Because of our
timing, we were forced to tackle issues that the Schemas WG has since solved,
which caused the "S" in SOAP to be somewhat lost.

At this point in time, I firmly believe that only two things are needed for mid-
to long-term convergence:
The XML Schemas WG should address the issue of typed references and arrays.
Adding support for these two synthetic types would obviate the need for SOAP
section 5. These constructs are broadly useful outside the scope of messaging
and RPC applications, so it makes sense that the Schemas WG should address this.
Define the handful of additional constructs needed to tie the representational
types from XML Schemas into operations and WSDL-style portTypes.

WSDL comes close enough to providing the necessary behavioral constructs to XML
Schemas, and I am cautiously optimistic that something close to WSDL could
subsume SOAP entirely. I strongly encourage you to study the WSDL specification
and submit comments, improvements, and errata so we can get convergence and
interoperability in our lifetime.
 

Part one of this article will attempt to give you a brief introduction to XML
and some simple examples that are of no use to practically anyone. Part two will
show you how to use Document Type Definitions (DTDs) to describe the elements in
an XML file and enforce rules. Part three will detail a real-world example that
will show you how to use XML to add RSS content to your web site. Don’t worry if
this doesn’t make sense just yet!
 

What is XML?
Directly from What is XML? by Norman Walsh: "XML is a markup language for
documents containing structured information." What does this mean? XML is a
markup language, just like HTML. The difference is XML is a markup language to
describe markup languages. You could actually implement HTML in XML (this is
actually being done). XML allows you to create markup for a structured document
that is standardized and can be used by anyone else who understands XML.

XML is a lot more finicky about syntax than HTML. Remember, HTML is displayed by
a finite number of software packages (usually web browsers) that more often than
not have workarounds for poorly written HTML. On top of that, HTML us usually
just displayed in a browser. This is not the case with XML, which may be
displayed in a browser, placed in a database, embedded in a spreadsheet etc.
Since XML can be used by any XML-enabled application, it must be properly
formed. Most XML parsers will just plain quit if they come upon ill-formed XML.

While we’re going to focus on data and presentation in this article, please keep
in mind this is not the only use to which XML can be put! There’s a myriad of
possibilities. This is one technology that actually might live up to its hype!
XML is platform independant and standardized, which means it isn’t tied to any
one operating system or platform, and its uses aren’t constrained by any
particular tools. The XML you use today in one application can and should be
used by applications not yet created!

Data and presentation
Let’s stop for a second and take a look at this table: Name Email address Phone
number
Niall niall@kst.com 555-1076
Sarah no.sarah@kst.com 555-0024
Jose no.jose@kst.com 555-5673

It’s a very simple table, with very simple data in it. Here’s the HTML code
for this table:
1 : <table border="1">
2 : <tr>
3 : <td bgcolor="#cccccc">Name</td>
4 : <td bgcolor="#cccccc">Email address</td>
5 : <td bgcolor="#cccccc">Phone number</td>
6 : </tr>
7 : <tr>
8 : <td>Niall</td>
9 : <td>niall@kst.com</td>
10: <td>555-1076</td>
11: </tr>
12: <tr>
13: <td>Sarah</td>
14: <td>no.sarah@kst.com</td>
15: <td>555-0024</td>
16: </tr>
17: <tr>
18: <td>Jose</td>
19: <td>no.jose@kst.com</td>
20: <td>555-5673</td>
21: </tr>
22: </table>
Nothing complicated about that, right? So what’s the problem? The problem is
that data (the actual names, email addresses, and phone numbers) is mixed right
in with the presentation (the HTML code that creates and displays the table). If
you want to change the way it looks, you might inadvertently change the data. If
you want to have more than one view of it, you have to create a separate HTML
file with the new view that duplicates the data you already have in the first
file. Now you have to worry about editing two files whenever the data changes!
And when you’re updating that data, what happens if you mess up the HTML code?

The answer to these problems is simple. Divorce the data from the presentation.
A stab at this was taken when cascading style sheets were first put into use,
but despite the fact that they are an excellent solution they never really
caught on. CSS support in browsers isn’t all that great, and implemented
differently across platforms and browser software. If we want to guarantee
things work and look the way we want them to we need XML.

The data
Let’s take a look at what the data might look like in an XML file (contact.xml):

1 : <?xml version="1.0"?>
2 : <contactList>
3 : <contact>
4 : <name>Niall</name>
5 : <emailAddress>niall@kst.com</emailAddress>
6 : <phoneNumber>555-1076</phoneNumber>
7 : </contact>
8 : <contact>
9 : <name>Sarah</name>
10: <emailAddress>no_sarah@kst.com</emailAddress>
11: <phoneNumber>555-0024</phoneNumber>
12: </contact>
13: <contact>
14: <name>Jose</name>
15: <emailAddress>no_jose@kst.com</emailAddress>
16: <phoneNumber>555-5673</phoneNumber>
17: </contact>
18: </contactList>

With just a glance, it’s easy to see what’s going on here. We have a contactList
that contains several contact elements. The contact elements in turn contain
name, emailAddress and phoneNumber elements. The first line tells us this is an
XML document that meets the standards of XML 1.0.

Without delving too heavily into syntax and formation, take special notice of
the fact that none of these elements overlap. If we open an element, we close it
immediately after the data it contains. While it might be possible to say "<font
size="+1"><b>Hello world!</font></b>" in an HTML document, it certainly would
not work with XML. The correct form would be "<font size="+1"><b>Hello
world!</b></font>", closing each element as we opened it.

If you think about it, this makes a great deal of sense. The whole advantage to
using XML is to define structure for your documents. If you closed the contact
element before you listed the accompanying phoneNumber element, how could you
know for sure what contact the phone number belonged to?

I won’t go heavily into syntax in this article. For an excellent overview and
introduction to XML, see the afore-mentioned What is XML? document by Norman
Walsh at xml.com.

The presentation
It’s great that we now have our data in a separate file, but how do we view it
in a way that makes sense to humans? Take a look at the XML file. People don’t
like to read marked-up source code; they like their information laid out in a
manner that makes sense to them, not a computer. This is where the eXtensible
Stylesheet Language (XSL) comes in.

In the same way that cascading style sheets provide style information for an
HTML document, XSL documents provide style information for XML data. And guess
what – they’re written in XML too. Here’s the XSL file we’ll use for our demo

There’s an awful lot of information floating around out there about XML and how
it’s reshaping the way we communicate, both to people (end users) and between
applications or processes. Introductions abound, giving simple examples of how
to separate data from presentation without presenting real world examples where
this makes sense. There are also many in-depth articles on practical uses of
XML, but these are often extremely complicated and rarely have anything to do
with the real world concerns of many developers (how many of you are developing
applications for the air-line industry?).

Part one of this article will attempt to give you a brief introduction to XML
and some simple examples that are of no use to practically anyone. Part two will
show you how to use Document Type Definitions (DTDs) to describe the elements in
an XML file and enforce rules. Part three will detail a real-world example that
will show you how to use XML to add RSS content to your web site. Don’t worry if
this doesn’t make sense just yet!

What is XML?
Directly from What is XML? by Norman Walsh: "XML is a markup language for
documents containing structured information." What does this mean? XML is a
markup language, just like HTML. The difference is XML is a markup language to
describe markup languages. You could actually implement HTML in XML (this is
actually being done). XML allows you to create markup for a structured document
that is standardized and can be used by anyone else who understands XML.

XML is a lot more finicky about syntax than HTML. Remember, HTML is displayed by
a finite number of software packages (usually web browsers) that more often than
not have workarounds for poorly written HTML. On top of that, HTML us usually
just displayed in a browser. This is not the case with XML, which may be
displayed in a browser, placed in a database, embedded in a spreadsheet etc.
Since XML can be used by any XML-enabled application, it must be properly
formed. Most XML parsers will just plain quit if they come upon ill-formed XML.

While we’re going to focus on data and presentation in this article, please keep
in mind this is not the only use to which XML can be put! There’s a myriad of
possibilities. This is one technology that actually might live up to its hype!
XML is platform independant and standardized, which means it isn’t tied to any
one operating system or platform, and its uses aren’t constrained by any
particular tools. The XML you use today in one application can and should be
used by applications not yet created!

Data and presentation
Let’s stop for a second and take a look at this table: Name Email address
Phone number
Niall niall@kst.com 555-1076
Sarah no.sarah@kst.com 555-0024
Jose no.jose@kst.com 555-5673

It’s a very simple table, with very simple data in it. Here’s the HTML code
for this table:
1 : <table border="1">
2 : <tr>
3 : <td bgcolor="#cccccc">Name</td>
4 : <td bgcolor="#cccccc">Email address</td>
5 : <td bgcolor="#cccccc">Phone number</td>
6 : </tr>
7 : <tr>
8 : <td>Niall</td>
9 : <td>niall@kst.com</td>
10: <td>555-1076</td>
11: </tr>
12: <tr>
13: <td>Sarah</td>
14: <td>no.sarah@kst.com</td>
15: <td>555-0024</td>
16: </tr>
17: <tr>
18: <td>Jose</td>
19: <td>no.jose@kst.com</td>
20: <td>555-5673</td>
21: </tr>
22: </table>
Nothing complicated about that, right? So what’s the problem? The problem
is that data (the actual names, email addresses, and phone numbers) is mixed
right in with the presentation (the HTML code that creates and displays the
table). If you want to change the way it looks, you might inadvertently change
the data. If you want to have more than one view of it, you have to create a
separate HTML file with the new view that duplicates the data you already have
in the first file. Now you have to worry about editing two files whenever the
data changes! And when you’re updating that data, what happens if you mess up
the HTML code?

The answer to these problems is simple. Divorce the data from the presentation.
A stab at this was taken when cascading style sheets were first put into use,
but despite the fact that they are an excellent solution they never really
caught on. CSS support in browsers isn’t all that great, and implemented
differently across platforms and browser software. If we want to guarantee
things work and look the way we want them to we need XML.

The data
Let’s take a look at what the data might look like in an XML file (contact.xml):

1 : <?xml version="1.0"?>
2 : <contactList>
3 : <contact>
4 : <name>Niall</name>
5 : <emailAddress>niall@kst.com</emailAddress>
6 : <phoneNumber>555-1076</phoneNumber>
7 : </contact>
8 : <contact>
9 : <name>Sarah</name>
10: <emailAddress>no_sarah@kst.com</emailAddress>
11: <phoneNumber>555-0024</phoneNumber>
12: </contact>
13: <contact>
14: <name>Jose</name>
15: <emailAddress>no_jose@kst.com</emailAddress>
16: <phoneNumber>555-5673</phoneNumber>
17: </contact>
18: </contactList>

With just a glance, it’s easy to see what’s going on here. We have a contactList
that contains several contact elements. The contact elements in turn contain
name, emailAddress and phoneNumber elements. The first line tells us this is an
XML document that meets the standards of XML 1.0.

Without delving too heavily into syntax and formation, take special notice of
the fact that none of these elements overlap. If we open an element, we close it
immediately after the data it contains. While it might be possible to say "<font
size="+1"><b>Hello world!</font></b>" in an HTML document, it certainly would
not work with XML. The correct form would be "<font size="+1"><b>Hello
world!</b></font>", closing each element as we opened it.

If you think about it, this makes a great deal of sense. The whole advantage to
using XML is to define structure for your documents. If you closed the contact
element before you listed the accompanying phoneNumber element, how could you
know for sure what contact the phone number belonged to?

I won’t go heavily into syntax in this article. For an excellent overview and
introduction to XML, see the afore-mentioned What is XML? document by Norman
Walsh at xml.com.
The presentation
It’s great that we now have our data in a separate file, but how do we view it
in a way that makes sense to humans? Take a look at the XML file. People don’t
like to read marked-up source code; they like their information laid out in a
manner that makes sense to them, not a computer. This is where the eXtensible
Stylesheet Language (XSL) comes in.

In the same way that cascading style sheets provide style information for an
HTML document, XSL documents provide style information for XML data. And guess
what – they’re written in XML too. Here’s the XSL file we’ll use for our demo

(contacts.xsl):
1: <?xml version="1.0"?>
2: <xsl:stylesheet xmlns:xsl="http://www.w3.org/TR/WD-xsl">
3: <xsl:template match="/">
4: <html>
5: <head>
6: <title>Contact list</title>
7: </head>
8: <body>
9 <table border="1">
10: <tr>
11: <td bgcolor="#cccccc">Name</td>
12: <td bgcolor="#cccccc">Email address</td>
13: <td bgcolor="#cccccc">Phone number</td>
14: </tr>
15: <xsl:for-each select="contactList/contact">
16: <tr><td>
17: <xsl:value-of select="name" />
18: </td><td>
19: <xsl:value-of select="emailAddress" />
20: </td><td>
21: <xsl:value-of select="phoneNumber" />
22 </td></tr>
23: </xsl:for-each>
24: </table>
25: </body>
26: </html>
27: </xsl:template>
28: </xsl:stylesheet>

Are you shocked to see this XML file contains mostly HTML? Don’t be. HTML
does an excellent job of presenting information. It’s just a lousy way to store
data. I’m sure new ways of presenting data will evolve over time, but HTML is
going to stay around for some time.

Keep in mind: since this is still an XML document you must open and close tags
properly, or it may not work at all!

Line 2 points to information that describes XSL, what it does, how it works.
We’re not going to touch on namespaces in this article, or explain every detail.
Rather we’ll give you an overview so you can see how it works.

Lines 4-14 are the first part of your HTML document, setting it up and creating
the table and cell headers.

Lines 15-23 are a simple for/next loop, which should be familiar to most
programmers. It tells the stylesheet to loop through contactList, find each
contact, and display a row containing their name, emailAddress and phoneNumber.
Lines 24-26 close up the HTML document, and lines 27-28 close up the stylesheet.

Now we need to bring the stylesheet together with the data…
Reuniting the data with the presentation
Now that we have our data, and we’ve defined how we want it displayed, we need
to bring them back together.

 Let’s take another look at contact.xml, which contains our data.
We’ve added an extra line, line 2:
1 : <?xml version="1.0"?>
2 : <?xml-stylesheet href="contacts.xsl" type="text/xsl"?>
3 : <contactList>
4 : <contact>
5 : <name>Niall</name>
6 : <emailAddress>niall@kst.com</emailAddress>
7 : <phoneNumber>555-1076</phoneNumber>
8 : </contact>
9 : <contact>
10: <name>Sarah</name>
11: <emailAddress>no_sarah@kst.com</emailAddress>
12: <phoneNumber>555-0024</phoneNumber>
13: </contact>
14: <contact>
15: <name>Jose</name>
16: <emailAddress>no_jose@kst.com</emailAddress>
17: <phoneNumber>555-5673</phoneNumber>
18: </contact>
19: </contactList>

Now we’ve linked the data to a stylesheet that tells us how to display it. If
you have an XML-capable browser (such as IE 5.x), you can take a look for
yourself. If you don’t have such a browser, I assure you, it looks like this:

Name Email address Phone number
Niall niall@kst.com 555-1076
Sarah no.sarah@kst.com 555-0024
Jose no.jose@kst.com 555-5673

Conclusion
We’ve touched lightly on XML, XSL, and bringing the two together. You might be
thinking it’s easier to just do it all in HTML. Using the data in our simple
examples? Certainly. Try to think beyond that to more complex situations where
the presentation code may be overwhelming, or when you’re dealing with large
amounts of data. What if you want more than one application to share the data?
Rather than embedding the data in each application you can define it once and
present it whatever way you like.

You might also be wondering "Why can’t I just do this with a database?". Again,
think beyond our simple examples. XML is all about sharing. It’s a common
denominator that spans platforms and operating systems, making XML data open to
all. In part two of this article we’ll give a real-world example using XML that
obtains headlines from popular news sites. The news sites store the information
in an XML document called a "Rich Site Summary" (RSS). Would it make sense to
put this information in a database? Would everyone be able to access it? Would
we possibly compromise security on our database by making portions of it
accessible to the public? These are a few of the reasons XML is ideal for this
sort of information sharing.

In this article, we’re going to explain what a Document Type Definition (DTD) is
and how it helps you describe and enforce rules on the mark-up (or elements) in
your XML documents.

What is a DTD?
We’re going to explain briefly, and then show you a simple use. A DTD is a file
(or group of files) that defines a certain kind of document. In a DTD you would
find valid element names and types, and (hopefully!) an explanation of how they
all fit together. We use DTDs to enforce rules on XML documents so that
applications can have an idea of what to expect from an XML document.

It’s all well and good to mark up and separate your data logically, but if the
end application doesn’t understand the data and how it all fits together then
we’re missing the point. DTDs help us understand XML documents and make sure
that we’re not storing data in a manner that might break applications.
Well formed and valid
In the previous article we made special care to ensure our XML documents were
well-formed; that is each tag is closed before a new one is opened. Documents
that aren’t well-formed will break most XML processors and are effectively
useless.

Using DTDs adds another term to our XML vocabulary: Valid. An XML document that
follows all the rules found in its specified DTD is said to be "Valid".

This means that though the "contacts" example in our previous example was "well
formed", it was not "valid" because we didn’t associate it with a DTD. The XML
parser had no way of knowing what constraints should be placed on the various
elements, nor did it know how to relate them to one another (though it is fairly
obvious just by looking at it).

Keep in mind that it’s often okay for your XML document not to be "valid".
Unless you have specific reasons for enforcing rules on your XML documents you
may be better off without a DTD.
Let’s look at our example
Let’s take a peek at our contacts.xml file from the previous article:
1 : <?xml version="1.0"?>
2 : <?xml-stylesheet href="contacts.xsl" type="text/xsl"?>
3 : <contactList>
4 : <contact>
5 : <name>Niall</name>
6 : <emailAddress>niall@kst.com</emailAddress>
7 : <phoneNumber>555-1076</phoneNumber>
8 : </contact>
9 : <contact>
10: <name>Sarah</name>
11: <emailAddress>no_sarah@kst.com</emailAddress>
12: <phoneNumber>555-0024</phoneNumber>
13: </contact>
14: <contact>
15: <name>Jose</name>
16: <emailAddress>no_jose@kst.com</emailAddress>
17: <phoneNumber>555-5673</phoneNumber>
18: </contact>
19: </contactList>
In case you’ve forgotten, gaze upon it and ponder its simplicity once again.

Let’s say the technical support department at kst.com starts using this XML file
and the accompanying style-sheet to store and display contact information. It’s
a very simplistic way of doing it, but by separating the data and presentation
they can use and import it into numerous applications as well as displaying it
on their website any way they choose.

One day, someone from kst.com’s marketing department stops by and sees it in
use, and like any person in any marketing department, they want it too. So the
marketing department starts using it to store their contact information. Rest
assured, as soon as the marketing department has it, all the other departments
will insist on having it also.

So now you have several departments using XML to store their contact
information. Great! The problem is, as it currently stands it’s not awfully
helpful; I mean, there’s no fax number, or street address, or any other
information besides a name, email address and phone number. The tech department
is quite happy the way it is, but it’s not enough for everyone else. So we add
some more elements:

1 : <?xml version="1.0"?>
2 : <?xml-stylesheet href="contacts.xsl" type="text/xsl"?>
3 : <contactList>
4 : <contact>
5 : <name>Niall</name>
6 : <emailAddress>niall@kst.com</emailAddress>
7 : <phoneNumber>555-1076</phoneNumber>
8 : <faxNumber>555-1000</faxNumber>
9 : <streetAddress>101 Elm Street</streetAddress>
10: <town>Anytown</town>
11: <state>MA</state>
12: <postalCode>02100</postalCode>
13: </contact>
14: <contact>
15: <name>Sarah</name>
16: <emailAddress>no_sarah@kst.com</emailAddress>
17: <phoneNumber>555-0024</phoneNumber>
18: <faxNumber>555-1000</faxNumber>
19: <streetAddress>101 Elm Street</streetAddress>
20: <town>Anytown</town>
21: <state>MA</state>
22: <postalCode>02100</postalCode>
23: </contact>
24: <contact>
25: <name>Jose</name>
26: <emailAddress>no_jose@kst.com</emailAddress>
27: <phoneNumber>555-5673</phoneNumber>
28: <faxNumber>555-1000</faxNumber>
29: <streetAddress>101 Elm Street</streetAddress>
30: <town>Anytown</town>
31: <state>MA</state>
32: <postalCode>02100</postalCode>
33: </contact>
34: </contactList>

If this were the real world, we would probably add more elements, but for the
purposes of our example we’re just adding elements for faxNumber, streetAddress,
town, state and postalCode.

We don’t run into any major problems yet, the folks using the new elements will
need new style-sheets so they can see them, and the tech support department can
still use their old stylesheet and ignore the new information that doesn’t
interest them. Everyone is happy! Now the departments can share their contact
information with each-other, only displaying the information that is of interest
to them.

That is, everyone is happy until Sarah from the sales department adds a new
element to each contact: personalityType. Not only that, but she’s populating
the new tag with the most ridiculous data. Clearly this tag should not be a part
of anyone’s contact listing, but Sarah is adamant in her refusal to remove it.
People are threatening to leave the company, racking up enormous therapy bills,
and are generally unhappy because of Sarah’s bad_contacts.xml.
DTDs to the rescue
Enter the DTD! Clearly we need to enforce some some of restraints on the
elements we allow in our contacts file. While we’re at it, it would be a good
idea to show how all these elements relate before we add more and it gets out of
hand and difficult to understand. This is the role that DTDs play for XML data.

Here’s the DTD we’ll use for our contacts, we’ll explain it below (contacts.dtd):

1 : <!ELEMENT contactList (contact)*>
2 : <!ELEMENT contact (name | emailAddress | phoneNumber
| faxNumber | streetAddress | town | state | postalCode)*>
3 : <!ELEMENT name (#PCDATA)>
4 : <!ELEMENT emailAddress (#PCDATA)>
5 : <!ELEMENT phoneNumber (#PCDATA)>
6 : <!ELEMENT faxNumber (#PCDATA)>
7 : <!ELEMENT streetAddress (#PCDATA)>
8 : <!ELEMENT town (#PCDATA)>
9 : <!ELEMENT state (#PCDATA)>
10: <!ELEMENT postalCode (#PCDATA)>

This is a very simple DTD containing only element declarations. There are other
things you can define with your DTDs (attribute lists, entities and notations),
but they are the subject of future articles. Please note we had to line break
line #2 for display purposes.

Hopefully this looks pretty straightforward: We have a declaration for each
element in our contacts.xml file. Let’s go through them and see what the DTD
tells us.

Line 1 defines an element, contactList. By looking at contacts.xml you’ll see
that this is our "main" element that contains all the contact elements. So in
our DTD we define the element contactList and let the parser know it is allowed
to contain the element contact. This is known as the content model of the
element contactList. The asterisk (*) means that the content is optional, and
may appear zero or more times. You can set restrictions on required elements,
optional elements etc. Again, this article is intended to be an introduction and
so we will not go into that just yet.

Line 2 is a little more meaty, since it defines the contact element, which may
contain several elements itself. They are separated with a bar (|) character,
which programmers may recognize as indicating an "or" relationship. The asterisk
again indicated that these elements may occur zero or more times. This is a very
relaxed declaration. If we had separated the entities with commas (,) it would
mean they must appear in the order we specify in order for the XML document to
be "valid". So we have now established that the contact entity may contain the
entities name, emailAddress, phoneNumber, faxNumber, streetAddress, town, state,
and postalCode.

Lines 3-10 define the remaining elements. You’ll notice that these elements do
not contain other elements like contactList and contact, they contain a special
symbol #PCDATA which means they will contain character data.

So now we have a DTD that defines all our elements and lets us know what belongs
in them. If an XML document attempts to validate off this DTD it needs to follow
these rules in order to be valid. That means that any tags in the XML document
have to be in the DTD, and they can only contain what the DTD allows. How do we
let our XML data know about these constraints?
Final contacts.xml
Here’s the final version of our XML file, new_contacts.xml:

1 : <?xml version="1.0"?>
2 : <!DOCTYPE contactList SYSTEM "contacts.dtd">
3 : <?xml-stylesheet href="contacts.xsl" type="text/xsl"?>
4 : <contactList>
5 : <contact>
6 : <name>Niall</name>
7 : <emailAddress>niall@kst.com</emailAddress>
8 : <phoneNumber>555-1076</phoneNumber>
9 : <faxNumber>555-1000</faxNumber>
10: <streetAddress>101 Elm Street</streetAddress>
11: <town>Anytown</town>
12: <state>MA</state>
13: <postalCode>02100</postalCode>
14: </contact>
15: <contact>
16: <name>Sarah</name>
17: <emailAddress>no_sarah@kst.com</emailAddress>
18: <phoneNumber>555-0024</phoneNumber>
19 <faxNumber>555-1000</faxNumber>
20: <streetAddress>101 Elm Street</streetAddress>
21: <town>Anytown</town>
22: <state>MA</state>
23: <postalCode>02100</postalCode>
24: </contact>
25: <contact>
26: <name>Jose</name>
27: <emailAddress>no_jose@kst.com</emailAddress>
28: <phoneNumber>555-5673</phoneNumber>
29: <faxNumber>555-1000</faxNumber>
30: <streetAddress>101 Elm Street</streetAddress>
31: <town>Anytown</town>
32: <state>MA</state>
33: <postalCode>02100</postalCode>
34: </contact>
35: </contactList>

Notice the new line #2, which tells us where to find the DTD that will validate
this document. This line points out the root element (contactList) of the
document, and points to the actual DTD that performs the validation. (The SYSTEM
keyword tells us the DTD is in a separate file, "contacts.dtd").

In order for the XML document to be "valid", it must meet the constraints of the
DTD. Sarah’s extraneous tags aren’t part of the DTD, so any changes she makes
will cause the document to be invalid. Unfortunately, though many parsers will
stop if a document is not well-formed, they will happily ignore DTDs. But at
least you understand them!

Conclusion
You might be wondering why it’s necessary to enforce rules on your data when you
can pick and choose what you want to display using style-sheets or other
methods. It’s important not to let your data get away from you. By placing
constraints on it you’re constantly aware of the data and what relationships it
has with itself (and other data!)

We’ve showed you how to store data in XML, present it using XSL, and now enforce
rules on it using DTDs. You’re ready for a real application now, and we’ll
tackle that in the next article; showing you how to use RSS files to feature
syndicated content on your website.

Whichever opinion you lean towards, one fact is clear: The Mozilla project has brought us the most standards compliant browser to date. However, this compliance comes with a price: It’s not backwards compatible with all the Netscape specific pages and tags. (At least, not yet. Netscape might pull an “all-nighter” at the last moment and add this support).

Back in the day when Netscape and Internet Explorer were fiercely competing for the browser market, each played dirty by adding their own tags and proprietary extensions to web pages in an attempt to “break” the other party’s browser. Truth be told, Netscape played a dirtier game than Microsoft — Microsoft’s browser is actually somewhat complaint with regards to the DOM (more on DOM in a bit!), Netscape totally ignored the DOM specifications put forth by the W3C and created their own methods of accessing the document’s methods and properties via their proprietary <layer> tags. This battle played out for a bit, and web pages with “Best viewed with XYZ browser” proliferated. As time progressed, expecting your audience to use your preferred browser became unacceptable. If your page needed to use dynamic features (like drop down menus, or collapsible outlines) you were expected to code for both browsers, thus ensuring everyone could take advantage of your content. Well, now you’ve got another browser to contend with, since your Navigator code will most likely fail to work under Mozilla/Netscape 6.

What is the “DOM”?
From the W3C’s specification: “a platform- and language-neutral interface that allows programs and scripts to dynamically access and update the content, structure and style of documents. The Document Object Model provides a standard set of objects for representing HTML and XML documents, a standard model of how these objects can be combined, and a standard interface for accessing and manipulating them. Vendors can support the DOM as an interface to their proprietary data structures and APIs, and content authors can write to the standard DOM interfaces rather than product-specific APIs, thus increasing interoperability on the Web.”

What does this mean? It’s an interface to tinker with your documents on the fly. Instead of negotiating with the web server every time you want to make something happen on a web page, the DOM allows you to tinker with the document’s makeup or structure and play with it on the fly, client side. At this point let me say that no browser is fully compliant with the specs. Mozilla ranks in closest, followed by Internet Explorer for the Mac, and then regular Internet Explorer. (Note that I have limited knowledge of other browsers, such as Opera. If anyone knows about its compliance level please let me know so I can amend this article!). Microsoft is also rebuilding their browser’s engine, so it’s uncertain if the next generation of IE for Windows will be more or less compliant.

As browsers move forward, it is in their best interests to become more and more compliant. The days of “Best viewed with XYZ browser” are behind us, and we’re moving towards the day when all our code will run happily on any user agent.

But we aren’t there yet.
A simple example
Lets take a look at a simple example of what we can do. Since this article is focusing on Mozilla/Netscape 6 we’ll target it for our examples. The examples should work under IE as well. We’ll also provide some pointers on how to write cross-browser pages in our next article so you don’t shut out all those old Netscape users.

Let’s make a quick collapsible list (quick_list.html):

1: <html>
2: <head>
3: <title>Mozilla/Netscape 6 collapsible list example</title>
4: <script language=”Javascript”>
5: function toggleIt(el) {
6: myEl = document.getElementById(el);
7: if (myEl.style.display == “block”) {
8: myEl.style.display = “none”;
9: } else {
10: myEl.style.display = “block”;
11: }
12: }
13: </script>
14: </head>
15: <body >
16: <div id=”parent1″>
17: <a href=”#” onClick=”toggleIt(’child1′)”>Introduction</a>
18: </div>
19: <div id=”child1″ style=”margin: 0px 10px; display: none”>
20: With the preview release of Netscape 6 (Alpha) the
21: Mozilla project is finally coming full circle. It’s
22: been about two years since the project’s inception,
23: and depending on who you ask it’s been a great
24: success or a horrible example of open-source gone
25: wrong.
26: </div>
27: <div id=”parent2″>
28: <a href=”#” onClick=”toggleIt(’child2′)”>What is the DOM?</a>
29: </div>
30: <div id=”child2″ style=”margin: 0px 10px; display: none”>
31: It’s an interface to tinker with your documents on
32: the fly. Instead of negotiating with the web server
33: everytime you want to make something happen on a
34: webpage, the DOM allows you to tinker with the
35: document’s makeup or structure and play with it
36: on the fly, client side.
37: </div>
38: </body>
39: </html>

What are we doing? Well, for starters you can see two types of <div> tags, “parents” and “children”. There’s nothing to be gained by giving the “parent” <div> tags a name except consistency and readability.

Notice on lines 19 and 30, where the two “child” <div> tags begin, the “style” settings. “margin: 0px 10px” tells the browser to display the contents of this <div> 0px down and 10px to the right of it’s parent element. This is called relative positioning, and we do it to visibly show that the contents of this <div> are subordinate to the parent <div>.

Notice also the “display: none”, which does exactly what you might think it does: tells the browser not to display the contents of this <div>. Why would we want to do that? Because that’s how we’re going to expand/collapse these items – by toggling the value of the “display” property. How do we do this? By accessing it via the DOM with the Javascript function “toggleIt()” starting on line 5.

We pass a single value to this function, the name of the child <div> to toggle. Once passed (as a string, not an object!) we get a reference to the actual object by calling document.getElementById(string). With this reference we can now tinker with the properties of the <div> tag. In this case we’re toggling the display property between “none” (don’t display it) and “block” (display normally).

We could have toggled the “visibility” property to hide/unhide the child elements, but this would not have produced the desired result. Instead of removing the child <div> from the document, it would merely make it “invisible”, leaving an ugly blank space where the text should be.

The next article in this series will explore a prototype for a “tree menu”, similar to those found in just about every file manager in existence. Stay tuned!

Benefits SELL! Trumpet your most important benefits in
the subheadings. This gives people in a hurry a fast track to
read. They can skim your subheadings to get your most
important ideas and selling points.

Subheadings make YOU exciting! Want to know one of
the main differences between a best-seller business book and
a boring text book on the same subject? The popular book
has far more subheadings. They break up the copy and
make it easier to read. Try using plenty of subheadings on
your website. Most people don’t like to read long copy on a
monitor.

Color works great in marketing. There are lots of theories
and opinions about what works best. Many say Blue lends a
feeling of quality and trust. Red makes people want to act,
now! Green makes people want to spend money (I’m a
little suspicious of this one, but some marketers swear it’s
true).


Yellow tends to get attention better than any other color,
but is hard on the eyes. Designers use Yellow to spice up a
headline or product name, but put the rest of the ad or
package in warmer colors.

One study showed that the color combination with the
most powerful psychological effect was yellow title, white
text, on a dark blue background.

Create an identity through all your marketing and products
with one or two colors you use over and over. This is a
very basic and effective way to tie all your stuff together in
the minds of customers.

Merle’s Cyber Promotions (MC) http://www.mcpromotions.com
Creating Visibility Online for Small Business… because just having a site
isn’t enough. Visit the site to receive FREE e-books packed with marketing &
promotional tips that will help your site get traffic. Also subscribe to MC
Promotions Press Newsletter to subscribe mailto:subscribe@m…

1) If you say something in a message and don’t want it
taken too seriously use something like- LOL, which stands for laughing out loud,
or type just kidding.

2) Never ever verbally assault someone with obscenities or
name calling even if they attacked first. Just because it’s e-mail and you can’t
see the person face to face, remember there’s a living breathing person at the
other end of that e-mail address with feelings. Besides you never know where
that email may end up later on and embarrass you.

3) I you feel as if you cannot
fully explain yourself in a message tell the other person to call you at their
convenience. Don’t demand, ask nicely and say "thank you".

4) Always answer your
e-mail within 24 to 48 hours. By not responding promptly it shows a lack of
interest on your part and is definitely unprofessional. By showing such a lack
of respect you may easily anger the party who’s been trying to get in touch with
you. If you’ll be away on vacation for any length of time set up an
autoresponder that answers your mail and notifies the sender that you are away
and when you’ll return. If you don’t know how to do this call your ISP for
assistance.

5) Always spell check every message for accuracy. Bad spelling and
grammar in a message can make someone form an opinion of you from that message,
and it’s not a good one.

6) Also never type in all caps as it means you ARE
SCREAMING at someone. It’s considered very rude. E-mail is a quick and
convenient way to communicate, but it’s important that your messages are
received as you intended.

By following these tips when dealing with your e-mail
you’ll be thought of as a professional and a pretty nice person as well!

Merle http://www.merlesworld.com Freebies for Webmasters and
a Whole Lot More! Subscribe to Merle’s Mission Newsletter by sending
mailto:subscribe@m… Secrets of Business in the New Millennium get the e-book
here http://www.merlesworld.com/tk.cgi?

It’s estimated that by the year 2002 there will be over 800 million wireless
users around the world. Eventually all wireless tools will come equipped with
WAP as standard issue. That’s a lot of possible viewers for your website. The
problem is that wireless net-surfers will not be able to access your HTML-driven
site. Their devices can only read sites built in (get ready for another
acronym!) WML.

WML stands for "Wireless Markup Language." (Are you taking notes here?) So if
you presently have a website built in HTML and you want mobile users to be able
to view it, you’ll need to make another version of it in WML. The good news is
that WML is not hard to learn and can be picked up easily. Plus, there are
plenty of sites online that will teach you everything you’ll ever want to know
about this new technology. Some of the better ones are:

http://www.wapdrive.net
Learn what WAP is (and isn’t), how to write WAP "cards" (not "pages"), and best
of all, you’ll find some free software you can download to make your own WAP
site. Free.
http://www.wapuseek.com
Contains Wap articles, links, tools and more. Make sure you stop in the
developers area for all kinds of webmaster tools for creating your own WAP
pages.

http://www.gelon.net/dev/
A ton of helpful information here: leaning WML, books, where you can host your
new WAP sites and more.

http://www.anywhereyougo.com
100% wireless application development: archives, news, books, and more. Sign up
for their helpful newsletter to keep abreast of what’s going on in this new
field.

As far as building your WAP site you can download free software or use an online
editor available at some websites.

http://www.wapmine.com
WAPPage 1.0 is an extensive and powerful design tool for WAP (Wireless
Application Protocol) Sites.

http://mobphone.com – WAP publishing tool for cellular mobile WAP phones.

For hosting your new wireless-enabled site, check out:
http://www.hoiley.com/ – Offering a variety of free services
http://www.tagtag.com/ – Build and host your site free
http://wappy.to – The first online WAPsite builder complete with hosting.

Keep in mind that the viewing area on a mobile device is a whole lot smaller
than that of a computer monitor. So you need to be short and concise. Plan on
about 10 text lines per WAP "card" (instead of "page.") Due to slow transmission
speeds typically 14.4 to 19.6 Kbps you need to keep text and graphics down to
bare minimum.

Wireless phones use "microbrowsers" to surf the web so you need to make sure the
web cards in WML look good on a wireless device. But what if you don’t have that
kind of luxury? No problem, hop over to http://www.wapdrive.net and you’ll find
something called "The Wapalizer" that will allow you to look at any WAP site
using your regular browser. Just type in the URL and a new window opens up that
imitates a mobile phones interface. You can browse through the entire site to
make sure everything will be viewed correctly by your mobile guests.

So there you have it. WAP and WML, two good things that just naturally go
together. If you presently have an HTML site you might want to consider making a
version of it in WML as a sidekick, thus opening yourself up to a whole new
audience; a mobile one.

After all, we’re a society on the move… and you’d better keep up!