1.2. Why XML Schemas?

XML provides a grammar for parsing a particular file or stream format. This XML grammar covers basic syntax, the most interesting being that of element tags and attribute specifications. Most applications need far more structure. XML schemas provide a mechanism for specifying more extensive grammar constraints. The ability to guide the layout of an XML document makes that XML document much more predictable. A programmer can examine an XML schema and know exactly what corresponding XML documents look like. Additionally, a program can reject an XML document out of hand when the XML does not conform to the appropriate XML schema.

An XML schema specifies valid elements and attributes in an XML instance. Furthermore, a schema specifies the exact element hierarchy (for nested elements). A schema specifies options (such as limits on the number of occurrences of a type of element) and various other constraints placed on the XML instance. In addition, a schema specifies a range for the value of an element or attribute.

1.2.1. What Is an XML Schema Document?

An XML schema document is the XML representation of all or part of an XML schema. Specifically, one or more XML schema documents describe an entire XML schema. Most of the elements in a schema document are XML representations of schema components; the other elements support assembling a schema from a set of schema documents.

1.2.2. Benefits of an XML Schema

XML schemas provide innumerable benefits to a development environment. Many of these benefits are intangible or economic in nature, indirectly increasing productivity and decreasing time-to-market.

The most important tangible aspect of an XML schema is that an XML schema specifies a contract between software applications or between parts of a software application. A developer creating software to generate XML, or an unfortunate employee who has to manually create XML, knows the target. A developer writing software that receives the XML not only knows what to expect, but can validate the incoming XML against the schema. As a specification of an interface, an XML schema might not be as easy to read as an English document, but it is incredibly precise. Furthermore, the writer can clarify the intent of a schema with XML comments and XML schema annotations—each with embedded English (or any other language).

For software development shops creating large applications, the notion of a contract simplifies modularization, resource allocation, testing, and deployment. Modularizing the code is easier because the boundaries are readily identifiable (each boundary is an XML document). This in turn makes resource allocation easier: Individual developers receive specific tasks, each of which has well-defined inputs and outputs. Testing is also much easier: The developer generating XML ensures that the generated XML validates against the XML schema, and the developer receiving the XML can easily create test XML documents in a common editor. Subsequently, integration testing is usually far more successful than with traditional data (such as passing objects and structures). Finally, even deployment is simpler: Versions of code that generate the XML can be deployed at different times than code that receives the XML—assuming that the schema is stable.

Modern distributed environments compound the issues just mentioned for a development shop. In particular, the developer writing software to process XML might be writing a Web service; anyone on the Internet could potentially generate XML that is sent to the Web service. In the case of a Web service, the XML schema is the crucial piece of documentation. Likewise, the XML schema is the contract by which everyone abides. For example, the developer can change the underlying Web service as long as the XML schema does not change. Likewise, developers know the exact target required by the XML schema.

1.2.3. Drawbacks of an XML Schema

From a practical perspective, one of the biggest hurdles for XML schemas is the learning curve. An XML schema is not easy to write; a good XML schema is even less easy. A good schema takes into account all boundary conditions—just like a good program.

XML schemas are incredibly precise; they are also verbose. This should come as no surprise to anyone who interacts frequently with the equally wordy plain XML, the foundation for XML schemas.

There is a noticeable amount of overhead to using XML. The XML verboseness just mentioned translates directly into extra overhead for deciphering XML. Understanding XML requires a full parser. A native programming structure (such as a C struct or a Java class) is much more efficient. XML validates against an XML schema. This validation is time-consuming. Worse, loading an XML schema document also requires parsing XML. As computers get faster and faster, developers tend to ignore the effort required from a processor. Of course, in some cases, the programmer can cache schema information for speed. Even so, a user might perceive the time delay caused by a single validation. Almost certainly, the amount of time required for multiple validations has the potential to annoy users.