Introduction

It was about five years ago, a few days after I finished my first book, when the publisher came to me with a rather enticing proposal: “Why don’t you start thinking about a new book?” Now I realize that all publishers make this sort of proposition, but at the time the proposal was definitely alluring, and a clear signal—I thought—of appreciation. “Because you seem to do so well with new technologies,” they said, “we’d like you to have a look at this new stuff called XML.” It was the first time I had heard about XML, which was not yet a W3C recommendation.

A lot of things have happened in the meantime, and XML did go a long way. You can be sure that, as I write this, a thousand or more IT managers are giving presentations that include XML in one way or another. Not many years ago, at a software conference, I heard a product manager emphasize the key role played by XML in the suite of products he was presenting. After the first dozen sentences to the effect that “this feature wouldn’t have been possible without XML,” one of the attendees asked a candid question: “Is there a function in which you didn’t use XML?” The presenter’s genuine enthusiasm led everyone there (including myself) to believe that programming would no longer be possible without a strong knowledge of XML. We were more than a little reassured by the speaker’s answer: “Oh no, we didn’t use XML in the compiler.”

Regardless of the hype that often accompanies it, XML truly is a key element in software. Today, XML is more than just a software technology. XML is a fundamental aspect of all forms of programming, as essential as water and air to every human being. Just as human beings realistically need some infrastructure to take advantage of water and air, programming forms of life must be supported by software tools to be effective and express their potential in terms of interoperability, flexibility, and information. For XML, the most important of these tools is the parser.

An XML parser reads in XML text and outputs a memory representation of the contents. The input for an XML parser is always plain and platform-independent text, although potentially encoded in a variety of character sets, whereas the output of an XML parser is strictly tied to the underlying hardware and software platform. Depending on the operating system and the programming environment of choice, an XML parser can generate a Component Object Model (COM) object as well as a Java or a JScript class. No matter the kind of output, however, the end result is XML data in a programmable form.

The growing level of integration and orchestration that partner applications need makes the exchanged XML code more and more sophisticated and often requires the use of specialized dialects like Simple Object Access Protocol (SOAP) and XPath. As a result, XML programming requires ad hoc tools for reading and writing in these dialects; all the better if the tools are tightly integrated into some sort of programming framework.

Effective XML programming requires that you be able to generate XML in a more powerful way than merely concatenating strings. The XML API must be extensible enough to accommodate pluggable technologies and custom functionalities. And it must be serializable and integrate well with other elements of data storage and exchange, including databases, complex data types (arrays, tables, and lists), and—why not?—visual user interface elements. In simple terms, XML must no longer be a distinct API bolted onto the core framework, but instead be a fully integrated member of the family. This is just what XML is in the Microsoft .NET Framework. And this book is about XML programming with the .NET Framework.