Foreword

“Too complicated! Way too much to learn! Nobody will understand this! Do we really have to implement this?”

XML is simple—why are XML schemas so complex?

In spite of early criticisms, World Wide Web Consortium (W3C) XML schemas have become an important part of our evolving information infrastructure. How important? Internet search engines can find over one quarter of a million documents that discuss XML schemas. Web Services, ebXML, OAGI, and most recent e-commerce specifications use W3C XML schemas. Vendors like BEA, IBM, Microsoft, Oracle, Sun, and a host of others have implemented schemas. In short, understanding XML Schema and its complexities has become essential for architects, developers, and managers who are building information-driven systems.

To understand Schema’s complexity, we have to look at its origins. In August of 1998, the group that developed XML gathered at the Metastructures 1998 & XML Developers Conference in Montreal to understand how the community at large was adopting our work. After the conference, 45 attendees gathered to outline how to continue what the XML 1.0 Recommendation had started. Schemas were one of the five work areas identified. Teams formed, chairs were nominated, and the effort began to formally charter working groups under the W3C. In November of 1998, we had our first meeting, gathering face-to-face in Chicago.

XML is simple. It is simple because during its creation, we were able to rely on over 100 years of combined experience in the Standardized Generalized Markup Language (SGML). This shared experience helped us to establish the ten design goals that are listed at the beginning of the XML 1.0 Recommendation. We had a common understanding of these goals; for example, when we declared, “It shall be easy to write programs which process XML documents,” we all meant that programmers should be able to write the basic code “over a holiday weekend.” XML’s simplicity is the direct result of asking ourselves, at nearly every meeting, “Is this necessary for success?” and using our shared experience and goals to answer “No” as much as possible.

XML schemas are complex. The W3C XML Schema Working Group did not have the benefit of a single, shared experience like SGML. The Working Group had to find a way to combine ideas and features from a wide variety of sources: Document Type Definitions (DTDs) from SGML; submissions to the W3C, including DDML, SOX, DCD, and XML-Data; and experience from other technology areas such as object-oriented programming, databases, and UML. The Working Group members, whose experience ranged from database standards, to e-commerce, to the study of ancient manuscripts, all brought needs and requirements with them.

For 30 months, the Working Group met 16 times face-to-face, held teleconferences once or twice a week, and formed dozens of task forces. We produced countless drafts and analyzed comments from thousands of reviewers. It became clear that we could not create a simple specification. This concerned the Working Group, yet we knew that it was important to finish our work and that others would fill in the gaps. In May of 2001 we released our three specifications and continued our work. As I write this, we are preparing the agenda for the 23rd face-to-face meeting.

Today, complaints continue, but at a much lower volume. Developers who are implementing schema-aware tools are filling one of the critical gaps. While these tools make it a lot easier for users of XML schemas, they cannot be expected to do all the work. Writing schemas is more than getting the syntax of XML Schema right. The schemas should be designed in such a way that the documents they describe are easy to author, update, and retrieve. They should be prepared for evolution and take into consideration corporate standards.

In fact, XML and XML schemas are now taking the enterprise world by storm. Understanding how to leverage their abilities is essential to those who already use XML in fields such as the Web, content and knowledge management, and e-business. But it is equally important that experts in other technologies, such as object-oriented or relational technology, build their understanding of XML schemas.

This book guides you through understanding schemas in a systematic way, from the basic concepts—type systems, type derivation, inheritance, and namespace handling—through advanced concepts in schema design. The early chapters describe the problem domain that schemas address. They provide insight into the motivations behind schemas and the problems that they can solve. The middle of the book delivers detailed explanations and examples of how to use the myriad features available in XML Schema and compares these to other similar languages. These chapters illustrate the design issues that the Working Group faced and that schema designers will face. The final chapters put it all together and describe how schemas can be applied to real applications.

Specifications such as the XML Schema Recommendations produced by the W3C Working Group must focus on defining technology and do not have the luxury of explaining motivation, design issues, and applications. This book fills that need admirably.