Sams Teach Yourself XML in 21 Days
- Table of Contents
- About the Author
- Acknowledgments
- We Want to Hear from You!
- Introduction
- Part I: At a Glance
- Day 1. Welcome to XML
- Day 2. Creating XML Documents
- Day 3. Creating Well-Formed XML Documents
- Day 4. Creating Valid XML Documents: DTDs
- Declaring Attributes in DTDs
- Day 6. Creating Valid XML Documents: XML Schemas
- Day 7. Creating Types in XML Schemas
- Part I. In Review
- Day 8. Formatting XML by Using Cascading Style Sheets
- Day 9. Formatting XML by Using XSLT
- Day 10. Working with XSL Formatting Objects
- Part II. In Review
- Part III: At a Glance
- Day 11. Extending HTML with XHTML
- Day 12. Putting XHTML to Work
- Day 13. Creating Graphics and Multimedia: SVG and SMIL
- Day 14. Handling XLinks, XPointers, and XForms
- Part III. In Review
- Part IV: At a Glance
- Day 15. Using JavaScript and XML
- Day 16. Using Java and .NET: DOM
- Day 17. Using Java and .NET: SAX
- Day 18. Working with SOAP and RDF
- Part IV. In Review
- Part V: At a Glance
- Day 19. Handling XML Data Binding
- Day 20. Working with XML and Databases
- Day 21. Handling XML in .NET
- Part V. In Review
- Appendix A. Quiz Answers
All About XML
Extensible Markup Language, XML, is really all about creating your own markup (technically, XML is a meta-language, which means it's a language that lets you create your own markup languages). Unlike HTML, XML is meant for storing data, not displaying it. XML provides you with a way of structuring your data in documents, and as mentioned at the beginning of today's discussion, the reason it's taken off so quickly is it's perfect for the Internet—because XML documents are text, you can send them using the existing Internet technology that was built for HTML.
You can package your great books collection as XML, or list all the books in a library, or all the types of fish in the sea; that's what XML is all about, and it's popular largely because restricted markup languages like HTML can't do that. Once you've packaged your data, you can send it over the Internet, and either other people or dedicated software you or others have created can understand it. There's an immense need to communicate data these days, from real estate listings to bank holdings, and XML is proving to be the way to do it.
XML was actually derived from Standard Generalized Markup Language, SGML, in 1998. SGML is a complex language, and was around for a long time without gaining widespread acceptance—but XML hasn't suffered from that problem. XML just turned five years old shortly before this book was written, and Jon Bosak, one of the people instrumental in XML's creation, wished XML happy birthday by saying, "The five years since XML was released have seen XML become the lingua franca of the Web." And it's true—using the markup you develop with XML, you can package your data so that data can be read by others. HTML is limited by having a limited amount of available markup; XML is limitless, because the markup you can create with it is also limitless.
XML is a creation of the World Wide Web Consortium (W3C) http://www.w3.org, which is the same group responsible for HTML and many other such specifications. W3C publishes its specifications (they're not called standards, technically, because W3C is not a government-sponsored body) using four types of documents, and if you want to work with XML and all its allied specifications, you have to be familiar with them:
- Notes— Specifications that were submitted to the W3C by an organization that is a member of the World Wide Web Consortium. W3C makes these specifications public, although doesn't necessarily endorse them, by publishing them as a note.
- Working drafts— A working draft is a specification that is under consideration, and open to comment. This is the first stage that W3C specifications must go through on their way to becoming recommendations.
- Candidate recommendations— Working drafts that the W3C has accepted become candidate recommendations, which means they're still open for comment. This is the second stage that W3C specifications must go through on their way to becoming recommendations.
- Recommendations— Candidate recommendations that the W3C has accepted become recommendations, which is the term the W3C uses when it publishes its specifications it considers ready for general use.
XML version 1.0 is in recommendation form, and has been since October 6, 2000, which means it's an established standard. You can find the formal XML 1.0 recommendation at http://www.w3.org/TR/REC-xml. There's a new version of XML now in candidate recommendation form, XML 1.1 (the latest version is October 15, 2002). You can find the XML 1.1 candidate recommendation at http://www.w3.org/TR/xml11/. As we'll discuss tomorrow, XML 1.1 improves on XML 1.0 by fixing a few errors, and by making the support for Unicode stronger.
What does an XML document actually look like? Let's take a look at one to get an idea of what's going on and how XML works. You can see a sample XML document, ch01_02.xml, in Listing 1.2.
Example 1.2. A Sample XML Document (ch01_02.xml)
<?xml version="1.0" encoding="UTF-8"?>
<document>
<heading>
Hello From XML
</heading>
<message>
This is an XML document!
</message>
</document>
We're going to dissect the kind of XML document you see in Listing 1.2 in detail tomorrow, but we'll get familiar with its structure today.
Like all XML documents, this one starts with an XML declaration, <?xml version="1.0" encoding="UTF-8"?>. This XML declaration indicates that we're using XML version 1.0, and using the UTF-8 character encoding, which means that we're using an 8-bit condensed version of Unicode (more on this tomorrow):
<?xml version="1.0" encoding="UTF-8"?>
<document>
<heading>
Hello From XML
</heading>
<message>
This is an XML document!
</message>
</document>
This XML declaration, <?xml?>, uses two attributes, version and encoding, to set the version of XML and the character set we're using (XML declarations also have other attributes, as you'll see tomorrow). XML attributes are much like HTML attributes—they hold additional information, and you create them by assigning a quoted value to the attribute as here: version = "1.0". (Unlike HTML attributes, you must always assign a value to an XML attribute if you use that attribute—there are no standalone attributes as in HTML.)
Next in ch01_02.xml, we create a new XML element named <document>. As in HTML, an element is the fundamental unit that you use to hold your data—all data in an XML document must be inside an element. Elements always start with an opening tag, which is the actual text <document> in this case, and end with a closing tag, which will be </document> here. (Note that this is similar to, but different from, HTML, where you don't always need a closing tag.) XML tags themselves always start with < and end with >. You create an XML element by pairing an opening tag with a closing tag, as we've done here to create the <document> element:
<?xml version="1.0" encoding="UTF-8"?>
<document>
.
.
.
</document>
Now you're free to store other elements in our <document> element, or text data, as we wish.
You're free to make up your own element names in XML, and that's XML's whole power—the capability to create your own markup. You don't have to call this new element <document>; you could have named it <data>, or <record>, or <people>, or <movies>, or <planets>, or many other things. As you'll see tomorrow, in XML 1.0, an element's name can start with a letter or underscore, and the characters following the first one are made up of letters, digits, underscores, dots (.), or hyphens (-)—but no spaces. XML 1.1 is more flexible about names, as you'll also see. Unlike HTML, the case of a tag is important—<DOCUMENT> is not the same tag as <document>, for example.
In between an element's opening tag and its closing tag, you can place the element's content, if there is any. An element's content can be made up of simple text or other elements. Like XML declarations, XML elements can support attributes.
When you create an XML document, you must enclose all elements inside one overall element, called the root element, also called the document element. The root element contains all the other elements in your XML document, and in this case, we've named the root element <document>. XML documents always need a root element, even if they don't have any other elements or text (that is, even if the root element doesn't have any other content).
Inside the root element, we'll add a new element, <heading>, to our XML document, like this:
<?xml version="1.0" encoding="UTF-8"?>
<document>
<heading>
.
.
.
</heading>
.
.
.
</document>
This new element will contain data in the form of text—"Hello from XML":
<?xml version="1.0" encoding="UTF-8"?>
<document>
<heading>
Hello from XML
</heading>
.
.
.
</document>
We will also add another element, which we'll name <message>, to the root element (there is no limit to the number of subelements an element can hold), holding the text data "This is an XML document!":
<?xml version="1.0" encoding="UTF-8"?>
<document>
<heading>
Hello From XML
</heading>
<message>
This is an XML document!
</message>
</document>
And that completes our first XML document. In this case, the root element, <document>, contains two elements, <heading> and <message>, both of which contain text (although they could contain other elements).
As you can see, this XML document looks like the HTML document we created earlier—the elements we've created here are surrounded by tags, just as in the HTML document. However, we just created the elements in the XML document out of thin air; we didn't have to stick to a predefined set. Being able to create your own elements from scratch like this has advantages and disadvantages—you're not restricted to a predefined and limited set of tags, but on the other hand, a standard Web browser can understand HTML tags but will have no idea what to do with a <message> tag.
We've stored our data in an XML document; to start interpreting that data, we'll begin by simply opening it in a browser.
Looking at XML in a Browser | Next Section

Account Sign In
View your cart