Getting Up To Speed With XML

May. 22, 2001 12:00 AM

XML. And XSLT, DTD, XPath, XSL-FO, XLink, XPointer, SAX, and DOM. To the uninitiated, all the talk about XML quickly dissolves into an alphabet soup of W3C recommendations, abbreviations, and acronyms.

This column, with a minimum of technobabble and a good dose of hands-on work, aims to indoctrinate you into the world of XML and to teach you how to use it for Web publishing. In the next 12 issues of XML-Journal, I'll use tutorials to expand your knowledge of XML and, after the first couple of columns, expose you to a different member of the XML family of technologies or to one of its close relatives.

Today I'll introduce you to XML and show how to create a simple XML document. The next column will pick up where this one leaves off and will discuss the fundamentals of structuring and marking up data. Subsequent columns will address such core XML technologies as XSL, DTDs, and XLink. Later in the year I'll turn to more advanced XML topics and related technologies: XSLT, XSL-FO, XML Schema, XPath, DOM, SAX, JSP, and Web publishing frameworks such as Apache Cocoon. Along the way I'll also touch on Cascading Style Sheets (CSS), XHTML, and Wireless Markup Language (WML) as well as on XML parsers, XSL processors, and a few handy XML tools.

To help you learn, each column will assign some related hands-on work to spur you to think about and work with the technology. The work will be of two kinds: 1. Reading references: To provide additional information.

2. Working with XML code or files: The coding will, at least during the first few columns, center on converting your résumé to XML and readying it for publication on the Web.

The degree of difficulty of the hands-on work - and indeed the column itself - is geared toward new users of XML, though I'll assume you have some knowledge of HTML. The column's primary target audience is anyone without a formal programming background - content authors, Web designers, HTML coders, technical writers, and amateur programmers - who wants to learn XML. Others are, of course, welcome, too.

For continuity each column will be structured in a similar manner. It will begin with an introduction that lays out its objectives and scope. The next section will present the background, concepts, and terminology necessary to understand the tutorial and to perform the hands-on work. Then the tutorial will demonstrate how to develop and apply the XML technology in question. The column's final section will assign a new hands-on task, review last month's column, and address e-mail from readers. Throughout the column I'll provide plenty of points of departure - references and resources, both online and in books - that you can pursue to find out more about those aspects of XML that interest you. As we proceed in this way, each subsequent column will extend the knowledge gained the previous month.

All this talk about XML begs the question: What is it anyway? And what about the jumble of abbreviations that cloaks XML from the curious eyes of an HTML coder or content author? How do XSLT, DTD, XLink, and all the rest fit into the XML equation?

Extensible Markup Language is, first and foremost, a metalanguage for describing and structuring data with tags. Metalanguage means a language used to describe other languages. Like HTML, XML uses tags (words bracketed by "<" and ">"), but, unlike HTML, XML has neither a predefined set of tags nor rules on how to use them (though XML does have generic rules governing markup; for instance, tags may not overlap). In XML, tags and their rules or grammar are defined by the users themselves. XML programmers use tags and their corresponding grammar to describe and structure data in a simple text format similar to HTML (as opposed to a binary format). Because users can define their own tags, XML, as its full name implies, is also extensible, meaning that unlike HTML it's capable of being extended. You'll begin learning how to create your own XML tags today in the tutorial section.

The hodgepodge of abbreviations and acronyms surrounding XML points up another of its characteristics: it's a family of technologies designed to be used over the Internet. Some of XML's family members and their main functions are as follows.

Extensible Stylesheet Language (XSL) XSL comprises Extensible Stylesheet Language Transformations (XSLT) and Extensible Stylesheet Language Formatting Objects (XSL-FO). It's an XML-based language for expressing stylesheets. XSLT is a language for transforming XML documents into (typically) other XML documents, HTML, and WML. XSL-FO is used to format XML documents for printing. My third column will present a tutorial on XSLT. Later columns will delve into XSL-FO and expand on XSLT.
Document Type Definition (DTD) Stemming from Standard Generalized Markup Language, the progenitor of both HTML and XML, a DTD defines the rules that constrain an XML document or a set of XML documents. In my fourth column I'll teach you how to construct a DTD.
XML Schema Thankfully we've been spared yet another abbreviation to remember. XML Schema may eventually supplant DTDs as the primary mechanism for constraining XML data. An XML Schema, which is in the format of an XML document, serves the same function as a DTD while correcting some of its limitations. This column will cover XML Schema later in the year.
XLink, XPath, and XPointer Together these provide the foundation for creating links and asserting relationships within and among XML documents. XLink describes how to create hyperlinks among XML documents and provides mechanisms for advanced capabilities such as multidirectional linking. XPath, widely used by XSLT, allows users to locate specific nodes or node sets within XML documents (you'll learn about nodes in the next column). XPointer specifies how to describe and point to locations of various kinds within an XML document. My fifth column will address linking in XML. For a quick description of it, check out "XML Linking: An Introduction" at www.stg.brown.edu/~sjd/xlinkintro.html.

Namespaces A specification that describes how to associate a URL with all the tags in an XML document to ensure they're unique, thereby eliminating ambiguity when the same tag is used by different XML coders. I'll introduce you to namespaces after we move through some of the more fundamental aspects of XML.
The Document Object Model (DOM) and the Simple API for XML (SAX) The Document Object Model, an application programming interface (API), is used to represent the structure and content of XML (and other) documents and provides an interface that allows programs and scripts to manipulate them. SAX, like DOM, also allows applications to get information from an XML document and do something with it. This column will provide an introductory tutorial on DOM and SAX toward the end of the year.

These are some of the XML-related technologies relevant to a broadly focused XML tutorial. As you may have guessed, there's a plethora of other XML-related specifications and applications, most of which are still evolving: XML Query, XML Base, XML Signature and Canonicalization, XML Protocol, MathML, SMIL, SVG, and FpML, to name a few. You can visit the World Wide Web Consortium's (W3C) Web site, www.w3c.org, for the rundown on most of these initiatives.

For a more complete description of what XML is and what its core-related technologies are, I'd like you to read two short pieces: an article on the W3C Web site called "XML in 10 Points," at www.w3.org/XML/1999/XML-in-10-points, and the first half of Chapter 1 in Brett McLaughlin's book, Java and XML, published by O'Reilly. For a slightly more technical introduction to XML, visit www.xml.com/pub/a/98/10/guide0.html.

Now that you have a sense of what XML is, let's jump into the language and begin working with it by creating a simple XML document from the top down.

An XML document typically comprises several fundamental components, all of which must be enclosed in angle brackets ("<" and ">"):

A processing instruction containing an XML declaration; this should be the first line of your XML document
A document type declaration
A root element
Other elements
Attributes
Comments

Processing instructions, which identify a task for an application to execute, start with <? and end with ?>. XML documents begin with a processing instruction that contains an XML declaration:

<?xml version="1.0" standalone="yes"?>

The attribute-value pair version="1.0" signals to the XML processor that the document conforms to version 1.0 of the XML specification, which was developed under the auspices of the W3C and is available at www.w3.org/TR/2000/REC-xml-20001006. The stand-alone attribute, which is optional and takes yes or no in either single or double quotation marks as its value, specifies whether an external DTD is required to parse the XML document. If the value of "standalone" is yes, an external DTD is not required.

Document type declarations, not to be confused with document type definitions, begin with <!DOCTYPE and perform two functions. They provide a list of document type definitions or specify the location of the file's external document type definition, and they identify the document's root element, also called its root node. Since XML documents don't need a document type definition to be well formed, I will, for now, skip this aspect of the declaration.

A root element, however, is required. All XML documents must have one (though it's not required to be declared with a document type declaration if the document doesn't use an internal or external DTD). In the following declaration, the root element is the word after <!DOCTYPE:

<!DOCTYPE resume>

Remember, you define your own tags in XML, so the root element can be any combination of permitted characters that you choose. Even though the root element has been specified in the document type declaration, it must still appear as the document's first element:

Besides a root element, XML documents typically contain a hierarchy of other elements, as this example shows:

<contactInfo>
<name>Steve Hoenisch</name>
<email>shoenish@rcn.com</email>
<phone></phone>
<address type="business">
<street>10 First Avenue</street>
<city>New York</city>
<state>New York</state>
<zip>10101</zip>
</address>
</contactInfo>

All elements, including the root, may optionally take one or more attribute-value pairs:

In XML, all values of attributes, including those in the processing instructions and declarations, must be enclosed in either single or double quotation marks. XML is not forgiving like HTML: no quotation marks around attribute values, no disco.

Comments begin with . Almost anything except a double hyphen ("--") may be placed inside the comment tags and be ignored by the XML processor. Comments may appear anywhere after the XML declaration. They may not, however, be embedded inside an element tag: <resume > won't work.

Listing 1 shows how these fundamental components can appear together in a simple document.

Let's consider some markup rules to which XML documents must adhere to be considered well formed. A well-formed document is one that conforms to XML syntax rules and contains correctly positioned elements and attributes. A valid XML document, in contrast, is one that conforms to the constraints of its DTD. For more on well-formed and valid documents, see Robert Eckstein's XML Pocket Reference, published by O'Reilly.

First, notice in Listing 1 that some of the elements are in mixed case. Unlike HTML, XML is case-sensitive: <contactinfo> is, to the XML processor parsing your document, a completely different tag from <contactInfo>. Though it doesn't matter what case or combination of cases you use, the name of an opening tag must match the name of its closing tag; otherwise your XML document is not well formed and the XML parser will fail to process it.

Second, an empty element - that is, one that contains no other elements or text, like <phone/> in the previous examples - must have a closing tag, which may be combined with the starting tag. Thus an empty element can be marked up either as <phone></phone> or as <phone/>.

Third, every nonempty element's opening tag must have a corresponding closing tag. If you open a nonempty element with <resume>, it must have a corresponding closing tag of </resume> that's properly nested, which brings us to our fourth rule: XML documents, again unlike HTML, may not contain any overlapping tags. Whereas <h2> Headline</h2> might work in HTML, it won't in XML.

Finally, as I've already mentioned, all attribute values must be enclosed in either single or double quotes.

Now I'd like you to start getting your hands dirty with XML by doing the following work to prepare for my next column:

Make sure you have version 5.0 or greater of Microsoft Internet Explorer installed on your computer. You can download it for free from www.microsoft.com/windows/ie/. Internet Explorer's XML parser allows you to debug and view XML files, and we'll be using it to do just that.
Use Notepad or, better, UltraEdit, a trial version of which is available at www.ultraedit.com/, to mark up your résumé or part of it with tags using not only elements but also attributes. As you do so, try to create tags that describe the structure or content of your résumé. Also, think about what aspects of your résumé's structure or content should be captured in attributes as opposed to elements. Don't worry about using a document type definition (but remember to set the value of the stand-alone attribute in the XML declaration to yes):
<?xml version="1.0" standalone="yes"?>)
Edit your marked-up document to make sure it's well formed, according to the rules I set out. Save it on your hard drive as a plain old text file (ASCII or Unicode on Windows NT) with an .xml file extension.
Next, open it in Internet Explorer and use Explorer to debug any problems with your markup. If you didn't craft your tags according to the rules I described, Explorer will display an error message that usually provides enough information to find and fix the offending code. Continue debugging your file until it displays as an XML page.

In next month's column I'll review an example of this hands-on assignment as well as cover the XML hierarchical tree model, examine different approaches to tagging, and discuss the importance of structured data.

Related Links

▪ Source Code

About Steve Hoenisch
Steve Hoenisch is a technical writer (consultant) with Verizon Wireless. Before becoming a technical writer and a Web developer, he worked as a journalist and teacher. Steve has been developing Web sites since 1996.