Line 2 of the example in the preceding section begins an element, which has been named authors. The contents of that element include everything between the right-angle bracket (>) in <authors> and the left-angle bracket (<) in </authors>. The actual syntactic constructs <authors> and </authors> are often referred to as the element start tag and end tag, respectively. Do not confuse tags with elements! Tags mark the boundaries of elements. Note that elements, like the authors element earlier, may include other elements as well as text. An XML document must contain exactly one root element, which contains all other content within the document. The name of the root element defines the type of the XML document.

Elements that contain both text and other elements simultaneously are classified as mixed content. Browsers support the use of mixed content, though other applications may not.

The sample authors document uses elements named person to describe the authors. Each person element has an attribute named id. Unlike elements, attributes can contain only textual content. Their values must be surrounded by quotes. You can use either single quotes (') or double quotes ("), as long as you use the same kind of closing quote as the opening one.

Within XML documents, attributes are frequently used for metadata (i.e., data about data)—describing properties of the element’s contents. This is the case in our example, where id contains a unique identifier for the person being described.

As far as XML is concerned, it does not matter in what order attributes are presented in the element start tag. For example, these two elements contain exactly the same information as far as an XML 1.0 conformant processing application is concerned:

<animal name="dog" legs="4"></animal>
<animal legs="4" name="dog"></animal>

On the other hand, the information presented to an application by an XML processor on reading the following two lines will be different for each animal element because the ordering of elements is significant:

<animal><name>dog</name><legs>4</legs></animal>
<animal><legs>4</legs><name>dog</name></animal>

XML treats a set of attributes like a bunch of stuff in a bag—there is no implicit ordering—whereas elements are treated like items on a list, where ordering matters.

New XML developers frequently ask when it is best to use attributes to represent information and when it is best to use elements. As you can see from the authors example, if order is important to you, elements are a good choice. In general, there is no hard-and-fast best practice for choosing whether to use attributes or elements, though elements can contain other elements and attributes, whereas attributes can contain only text.

The final author described in our document has no information available. All we know about this person is his or her ID, mysteryperson. The document uses the XML shortcut syntax for an empty element. The following is a reasonable alternative:

<person id="mysteryperson"></person>

XML 1.0 has certain rules about element and attribute names. In particular:

You can find a precise description of names in Section 2.3 of the XML 1.0 specification, at http://www.w3.org/TR/REC-xml#sec-common-syn.

XML 1.0 lets developers create their own elements and attributes, but leaves open the potential for overlapping names. “Title” in one context may mean something entirely different from “Title” in a different context. The namespaces in the XML specification (which you can find at http://www.w3.org/TR/REC-xml-names/) provide a mechanism by which developers can identify particular vocabularies using Uniform Resource Identifiers (URIs).

URIs are a combination of the familiar Uniform Resource Locators (URLs) and Uniform Resource Names (URNs). From the perspective of XML namespaces, URIs are convenient because they combine an easily used syntax with a notion of ownership. Although it is possible for me to create namespace URIs that begin with http://microsoft.com, general practice holds that it would be better for me to create URIs that begin with http://holdener.com, a domain I own, and leave http://microsoft.com to Microsoft. In general, organizations and individuals who create XML vocabularies should choose a namespace URI in a space they control. This makes it possible (though it is not required) to put information there documenting the vocabulary, or other resources for processing the vocabulary.

The rules for XML names do not permit developers to create elements with names such as http://holdener.com/ns/mine:Title, and working with such names wouldn’t necessarily be much fun anyway. To get around these problems, the namespaces in the XML specification define a mechanism for associating URIs with element and attribute names through prefixes. Instead of typing out the whole URI, developers can work with a much shorter prefix, or even set a default URI that applies to names without prefixes.

To create a prefix, you use a namespace declaration, which looks like an attribute. For example, to create a prefix of xhtml associated with the URI http://www.w3.org/1999/xhtml, you would use an xmlns:xhtml attribute, as shown here:

<container xmlns:xhtml="http://www.w3.org/1999/xhtml" >
.
.
.
</container>

To apply a prefix, you put it in front of the element or attribute name, with a colon separating the prefix from the name. To put an XHTML <p> element inside that container, you could write:

<container xmlns:xhtml="http://www.w3.org/1999/xhtml" >
<xhtml:p>This is an XHTML paragraph!</xhtml:p>
</container>

When a program encountered the xhtml:p, it would know that p was the local name of the element, xhtml was the prefix, and http://www.w3.org/1999/xhtml was the URI for that element. The namespace declaration applies to all elements inside the element where it appears, as well as the element containing the declaration. For example, the xhtml prefix works for all three of these paragraphs:

<container xmlns:xhtml="http://www.w3.org/1999/xhtml" >
<xhtml:p>This is XHTML paragraph 1!</xhtml:p>
<xhtml:p>This is XHTML paragraph 2!</xhtml:p>
<xhtml:p>This is XHTML paragraph 3!</xhtml:p>
</container>

In most XML processing, the prefix does not matter; the local name and the URI are what counts, and the prefix is just a mechanism for associating them. (This is especially important in XSLT processing and XML Schemas.) In some documents, particularly ones that use structures from only one namespace or where one vocabulary is dominant, developers choose to use the default namespace rather than prefixes. When the default namespace is used (assigned with an xmlns attribute), elements without a prefix are associated with a given URI. In XHTML, an XML derivative of HTML, this is the most typical path, because HTML developers are not used to putting prefixes on all of their element names. A typical XHTML document might look like this:

<html xmlns="http://www.w3.org/1999/xhtml">
    <head>
        <title>My Document</title>
    </head>
    <body>
        <p>Could use some content here</p>
    </body>
</html>

In this case, the URI http://www.w3.org/1999/xhtml applies to every element in the document, including <html>, <head>, <title>, <body>, and <p>. The default namespace has one quirk, though: it does not apply to attributes. You can give attributes a namespace by explicitly using a prefix in their name, but unprefixed attributes have no namespace URI. This often does not matter, but it can be important when writing XSLT stylesheets and creating XML Schemas.

Typically, the namespaces a document uses are declared on the root element of the document, which lets the namespaces apply to all the content inside that document. Of course, you also can declare them throughout the document, though this makes it more difficult to read. Declarations can override one another as well, and the declaration closest to a given use of a prefix in the hierarchy will be used. This lets developers mix and match XML vocabularies even when they use the same prefix.

Namespaces are very simple on the surface but are a well-known field of combat in the XML arena. For more information on namespaces, see Tim Bray’s “XML Namespaces by Example,” published at http://www.xml.com/pub/a/1999/01/namespaces.html; or the aforementioned books XML in a Nutshell and Learning XML.

An XML document that conforms to the rules of XML syntax is described as well formed. At its most basic level, being well formed means the elements are properly matched, and all opened elements are closed. You can find a formal definition of well formed in Section 2.1 of the XML 1.0 specification, at http://www.w3.org/TR/REC-xml#sec-well-formed. Table A-1 shows some XML documents that are not well formed.

<foo>
    <bar>
    </foo>
</bar>

<foo>
    <bar>
</foo>

<foo bar>
</foo>

<foo bar=23>
</foo>

As in HTML, it is possible to include comments within XML documents. XML comments are intended to be read only by people. With HTML, developers have occasionally employed comments to add application-specific functionality. For example, the server-side include functionality of most web servers uses instructions embedded in HTML comments. In XML, comments should not be used for any purpose other than those for which they were intended, as they are usually stripped from the document during parsing.

The start of a comment is indicated with <!--, and the end of the comment with -->. Any sequence of characters, aside from the string --, may appear within a comment. Comments can appear at the start or end of a document as well as inside elements. They cannot appear inside attributes or inside a tag. A comment might look like this:

<!--Hello, this is a comment -->

Comments tend to be used more in XML documents intended for human consumption than those intended for machine consumption. If you want to pass information to an XML application without affecting the document’s structure, you can use processing instructions, or PIs. PIs use <? as a starting delimiter and ?> as a closing delimiter, must contain a target conforming to the rules for XML names, and may contain additional data. A typical PI might look like this:

<?xml-style type="text/css" href="mystyle.css" ?>

In this case, xml-style is the target and type="text/css" href="mystyle.css" is the data. For more information on PIs, see Section 2.6 of the XML 1.0 specification, at http://www.w3.org/TR/REC-xml#sec-pi.

You may occasionally need to use the mechanism for escaping characters. Because some characters have special significance in XML, you need a way to represent them. For example, in some cases the < symbol might really be intended to mean “less than” rather than to signal the start of an element name. Clearly, just inserting the character without any escaping mechanism would result in a poorly formed document because a processing application would assume you were starting another element. Another instance of this problem is the need to include both double quotes and single quotes simultaneously in an attribute’s value. Here is an example that illustrates both difficulties:

<badDoc>
    <para>
        I'd really like to use the < character
    </para>
    <note title="On the proper 'use' of the " character"/>
</badDoc>

XML avoids this problem by the use of the predefined entity reference. The word entity in the context of XML simply means a unit of content. The term entity reference means just that: a symbolic way to refer to a certain unit of content. XML predefines entities for the following symbols: left-angle bracket (<), right-angle bracket (>), apostrophe ('), double quote ("), and ampersand (&).

An entity reference is introduced with an ampersand (&), which is followed by a name (using the word name in its formal sense, as defined by the XML 1.0 specification), and terminated with a semicolon (;). Table A-2 shows how the five predefined entities can be used within an XML document.

Here is our problematic document revised to use entity references:

<badDoc>
    <para>
        I'd really like to use the &lt; character
    </para>
    <note title="On the proper &apos;use&apos;  of the &quot;character"/>
</badDoc>

Being able to use the predefined entities is often all you need; in general, entities are provided as a convenience for human-created XML. XML 1.0 allows you to define your own entities and use entity references as “shortcuts” in your document. Section 4 of the XML 1.0 specification, available at http://www.w3.org/TR/REC-xml#sec-physical-struct, describes the use of entities.

You may find character references in web services that pass information with XML. Character references allow you to denote a character by its numeric position in the Unicode character set (this position is known as its code point). Table A-3 contains a few examples that illustrate the syntax.

Note that you can express the code point in decimal or, with the use of x as a prefix, in hexadecimal.

Character encoding is frequently a mysterious subject for developers. Most code tends to be written for one computing platform and, normally, to run within one organization. Although the Internet is changing things quickly, most of us have never had to think too deeply about internationalization.

XML, designed to be an Internet-friendly syntax for information exchange, has internationalization at its very core. One of the basic requirements for XML processors is that they support Unicode standard character encoding. Unicode attempts to include the requirements of all the world’s languages within one character set. Consequently, it is very large!

In addition to being well formed, XML 1.0 offers another level of verification, called validity. To understand why validity is important, imagine that you invented a simple XML format for your friends’ telephone numbers:

<phonebook>
    <person>
        <name>Albert Smith</name>
        <number>123-456-7890</number>
    </person>
    <person>
        <name>Bertrand Jones</name>
        <number>456-123-9876</number>
    </person>
</phonebook>

Based on your format, you also construct a program to display and search your phone numbers. This program turns out to be so useful that you share it with your friends. However, your friends are not as hot on detail as you are, and they try to feed your program this phone book file:

<phonebook>
    <person>
        <name>Melanie Green</name>
        <phone>123-456-7893</phone>
    </person>
</phonebook>

Note that although this file is perfectly well formed, it doesn’t fit the format you prescribed for the phone book because there is a phone element where there should have been a number element. You will likely need to change your program to cope with this situation. If your friends had used number as you did to denote the phone number, and not phone, there would not have been a problem. However, as it is, this second file probably will not be usable by programs set up to work with the first file; from the program’s perspective, it is not valid.

For validity to be a useful general concept, we need a machine-readable way to say what a valid document is; that is, which elements and attributes must be present and in what order. XML 1.0 achieves this by introducing document type definitions (DTDs).

<?xml version="1.0" encoding="us-ascii"?>
<!DOCTYPE authors SYSTEM "http://example.com/authors.dtd">
<authors>
    <person id="lear">
        <name>J.K. Rowling</name>
        <nationality>British</nationality>
    </person>
    <person id="lewis">
        <name>C.S. Lewis</name>
        <nationality>Irish</nationality>
    </person>
    <person id="mysteryperson"/>
</authors>

XSLT developed in several distinct stages to become what it is today. These changes occurred as more developers began to use and understand XML and XSL, and the requirements for its definition needed to change along the way to accommodate ideas:

The XSLT stylesheet defines the transformations that should process the XML data being referenced. XSLT has traditionally been handled by external processes, often on the server, but some modern browsers are now handling transformations themselves. XML documents can specify which stylesheets are most appropriate for their processing. For example:

<?xml-stylesheet type="text/xml" href="transform.xsl"?>

This declaration must be made as part of the prolog of the XML document.

<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
.
.
.
</xsl:stylesheet>

The <xsl:stylesheet> and <xsl:transform> elements I just introduced are examples of the XSLT elements available to create an XSLT document. In the following sections, I will discuss some of the more commonly used elements and how to use them in an XSLT document. Learning XSLT, by Michael Fitzgerald (O’Reilly), is a good resource for all of the XSLT elements.

<xsl:template match="person">
    <div>
        <xsl:text>Name: </xsl:text>
        <strong><xsl:value-of select="name" /></strong>
    </div>
    <div>
        <xsl:text>Number: </xsl:text>
        <strong><xsl:value-of select="number" /></strong>
    </div>
</xsl:template>

<xsl:text>Name: </xsl:text>

<xsl:value-of select="name" />

<xsl:for-each select="person">
    <div>
        <xsl:text>Name: </xsl:text>
        <strong><xsl:value-of select="name" /></strong>
    </div>
    <div>
        <xsl:text>Number: </xsl:text>
        <strong><xsl:value-of select="number" /></strong>
    </div>
</xsl:for-each>

<xsl:for-each select="person[name='Anthony Holdener'">
    <div>
        <xsl:text>Name: </xsl:text>
        <strong><xsl:value-of select="name" /></strong>
    </div>
    <div>
        <xsl:text>Number: </xsl:text>
        <strong><xsl:value-of select="number" /></strong>
    </div>
</xsl:for-each>

<xsl:for-each select="person">
    <xsl:if test="name='Anthony Holdener'">
        <h3><xsl:text>The author of this book!</xsl:text></h3>
    </xsl:if>
    <div>
        <xsl:text>Name: </xsl:text>
        <strong><xsl:value-of select="name" /></strong>
    </div>
    <div>
        <xsl:text>Number: </xsl:text>
        <strong><xsl:value-of select="number" /></strong>
    </div>
</xsl:for-each>

<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
    <xsl:output method="xml" omit-xml-declaration="yes" />
    <xsl:template match="/phonebook">
        <xsl:apply-templates select="person" />
    </xsl:template>

    <xsl:template match="person">
        <xsl:if test="name='Anthony Holdener'">
            <h3><xsl:text>The author of this book!</xsl:text></h3>
        </xsl:if>
        <div>
            <xsl:text>Name: </xsl:text>
            <strong><xsl:value-of select="name" /></strong>
        </div>
        <div>
            <xsl:text>Number: </xsl:text>
            <strong><xsl:value-of select="number" /></strong>
        </div>
    </xsl:template>
</xsl:stylesheet>

<xsl:apply-templates select="book[@title=current( )/@ref]" />