Taming the XML Beast

For the past couple of years, XML evangelists have preached that XML will save us from the problems that plague today's Web documents. You can't turn anywhere in Internet news without hearing some mention of XML. XML now seems to be an essential tool for current and future business transactions and for resolving coding incongruities as well.

Naturally, you want to find out what the hype is all about and see how XML works. But many people attempting to learn XML find the strict rules and cryptic code a bit daunting. Without a defined set of tags such as in HTML, you just don't know where to start. While developing a successful XML-based application connected to a large reservoir of data requires lots of planning and work, learning the basics of XML really isn't that difficult. By following a few simple yet crucial syntax rules and understanding how the different parts work together, anyone can write an XML document.

I'll begin by describing some basic XML concepts, and then show you how to write XML elements and attributes. If you've been keeping up to date on the latest XHTML specifications, you've got a good basic foundation for XML. Since most of you probably know HTML, I'll use that as a point of reference and comparison for my examples here. I'll also follow this foundational article with a companion article that provides more details about XML, its syntax and rules, and how to give XML documents style.

XML Concepts

Way back in the pre-Web days, SGML (Standard Generalized Markup Language) stood as a powerful metalanguage, used for the creation of technical documentation. Seeking a means to deliver document management markup over the Web, it only made sense to look to SGML. But SGML is complicated, and early Web markup needed to be streamlined. So HTML was developed from SGML, but in a very simplistic way.

That simplicity ended quickly due to the rapid evolution of new tags that departed from basic markup and entered into the realm of presentation. As a result, HTML in its present form has problems and limitations. It has a fixed set of tags that hold no meaning about the data they contain, and browser tolerances for nonstandard coding do nothing to discourage sloppy coding practices. To make up for these problems, developers decided to revisit the original intelligent structure of SGML to look for highly structured solutions to HTML's problem. Out of this re-examination emerged XML, which has most of the power of SGML but without its complexities.

XML, eXtensible Markup Language, really isn't a markup language. It's a metalanguage—meaning it's a language, or more specifically, a set of syntax rules and guidelines, used to create markup languages.

XML is all about the data. After all, it's the data that is important. There's nothing in XML to allow you to format the data, it's about describing and structuring documents.

To write an XML document, you need to do nothing more than create an ASCII text file. This can be done with any text editor, such as Windows Notepad. To view an XML document, you just load the file into a browser with XML parsing capabilities, such as Mozilla or IE5. For our purposes, IE5 will work just fine since more people have it.

When you view your data, you'll notice that it's just that—data. There is no style involved in XML itself. To style your data for presentation, you can use a styling language, like CSS, or another XML-based application like XSL (eXtensible Style Language) or XSLT (XSL Transformations). Separating the style markups from your data structure means you can maintain the integrity of your data. This is a core issue with XML, and one I'll look at more closely in a follow-up article.

XML Syntax: Elements and Tags

A good way to think about XML is as building blocks for constructing a set of tags to describe the different pieces of data in your document. For those of you who have been using "tags" and "elements" interchangeably, know that there is a difference. Tags are the markup code denoted by the < and > signs, such as in the start tag <h1> and end tag </h1> with a forward slash.

An "element" is the construct of the tag pair and its contents, as in:

<h1>Taming the XML Beast.</h1>

The entire line is considered the <h1> element, "h1" is the element name, and everything between the start and end tags is considered the element content, in this case, it's the data "Taming the XML Beast." This distinction is important to understand because in XML, you not only make up names for the markup tags, but you can also define what contents those tags contain.

Although you create your own set of markup tags—the "vocabulary" of your new markup language—the elements are not without order. When you write up an XML document, there is a hierarchical structure in how your data is organized, what sequence it follows, and what it contains. One point that will come up again and again, is that XML is all about the data.

Take for example, the HTML table data, td, cell element. This element must be contained within a tr table row element, which in turn must be contained within a table element. Although the HTML table elements hold no meaning in regard to the data, your XML markup elements would be constructed following a similar order.

Suppose you want to create an XML document listing all the test scores of the students in several computer classes you're teaching. You would probably want to list all the scores under each student, who in turn would be listed within each class. But instead of the abstract cells and rows of HTML, in XML, you denote those areas with data-related names, such as class, test, student name, and score. Instead of a <td>, you could end up with <student_name> for your tag, which provides details about—you guessed it—the data it contains.

That's not to say you have to organize your data in such a manner. Your data could all have a single level of importance, and you would need to be concerned with only the sequence in which they appear. It really depends on what your data is. So the first step in writing an XML document is to think about what data you have, and how it should be organized.

Name that Tag!

Coming up with new names for your tags is the fun part. You've looked over your data to determine what's there and what needs to be categorized. Now you'll assign meaningful names to them. You'll choose a word that clearly describes the data. There's no practical limit to the length of your element names, but the longer the names, the more verbose your document will end up, not to mention the more typing you will have to do!

There are some basic rules to naming XML tags:

• XML is case sensitive.
• Element names may start with any letter or an underscore (_).
• After the first character, element names may contain letters, numbers, periods (.), hyphens (-), underscores (_) or colons. (:).
• Element names may not contain white spaces.
• Element names may not start with "XML" or any case variations of these letters. These are reserved by the World Wide Web Consortium (W3C).

HTML originally started out as a way to structure a document. You have <h1> to <h6> heading levels to signify the levels of importance—not font size and weight as they are rendered in today's browsers. Then, as people sought to control a Web page's appearance, presentation tags such as the infamous <font> tag came onto the scene. But these tags really don't tell you anything about the data itself, and computers certainly can't distinguish data from HTML. For example, if you tried searching for "bears", it makes no distinction between North American Grizzlies, a Chicago football team, or recessions in the stock market.

The beauty of creating your own tag sets is in the ability to assign self-describing names for your data. Following the bear example:

<animal>Grizzly Bear</animal>
<FootballTeam>Chicago Bears</FootballTeam>
<market_trend>Bear Market</market_trend>

Remember that XML is case sensitive. Unlike HTML, where case doesn't matter, the XML parser sees <animal>, <ANIMAL>, and <aNiMaL> as different tags.

XML Attributes

Attributes are used to describe the element. If elements are akin to nouns, think of attributes as adjectives modifying the noun. Attributes are written in an element's start tag with the name of the attribute, followed by an equal sign (=) and a value given to that attribute.

An HTML example would be <hr width="50%">. This tag tells the browser to put a horizontal rule on the page. The width attribute defined here says that this horizontal rule should be set to a width of 50% of the available width space.

Attribute naming rules are the same as those for element names. In addition, a tag may not have two attributes with the same name.

Here's a sample of an element with an attribute:

<book call_no="PZ3.S8195Gr6">

A question often arises as to whether to make something a child element or an attribute. There's no rule that says you have to do it one way or another, but a good way to help decide is to know the functions of each. Element contents, generally speaking, are meant to be displayed—data that is parsed on the screen. Think of attributes as data about the data; that is, it's information that is more important to the parser than to the reader of the data, so it's not rendered on the screen.

Why XML?

A big lure of XML is that it allows you to create your own tags for your data. Various companies are working collaboratively on building common tag sets in their various industries to give them compatible data structures for data exchange. XML also allows us to build more powerful languages or improve on old ones, such as with XHTML, which is essentially the HTML 4.0 tag set redefined with XML rules. As long as data exists, any author can create an XML vocabulary to meet his or her needs.

As you've noticed, you first approach XML by identifying and organizing your data. This is very different from HTML, where many Web designers start a new Web page as if it was a blank canvas and "paint" data into place. Remeber, XML is all about the data.

In the second part of this article, I'll explain how to put your tag set into an XML document for display in a Web browser. Other interesting things we'll cover include defining how your tag set can be used, and styling XML data to look presentable.

Bonnie is a technical writer who designs and develops Web sites and creates system documentation.