Appendix A: XML Schema

Overview

XML Schema definition language (XSD) is referenced throughout this book. XML Schema is a widely accepted mechanism for defining business rules for XML instance documents. Most Web service specifications-from SOAP to WSDL to BTP-use XML Schema to define their XML message vocabularies. A working knowledge of XML schema is a prerequisite to fully understanding the different Web service specifications. This appendix serves as a quick tutorial and also as a quick reference for the most common XML Schema elements.

The XML used to represent a list of Flute Bank employees' data might look like Listing A.1.

Listing A.1: employeeList XML

<?xml version="1.0" encoding="UTF-8"?>
<employeeList>
   <employee type="contract">
      <employee_id>75868</employee_id>
      <name>
          <first_name>John</first_name>
          <last_name>Doe</last_name>
      </name>
      <extn>27304</extn>
      <dept>1104332089</dept>
      <email>john.doe@flute.com</email>
   </employee>
/employeeList>

While this XML is well formed-that is, without syntax errors-how does an XML parser at Flute know that this represents an employee, as defined by Flute Bank's business? For example, Flute Bank's business rules may state that

A list of Flute Bank employees consists of zero or more employees and that an employee is described fully by providing the employee's ID, name, phone extension, department, and email.
All employees must be classified as either "permanent" or "contract."
Department numbers within the bank are ten digits and are of the form "999-999-9999".
Employee IDs are nonnegative integers between 1 and 100,000.

These rules can be broadly classified into two categories: those that pertain to the XML structure and those that pertain to the datatypes and allowed values of individual elements and attributes. XML Schema is an XML grammar and vocabulary used to define and describe the allowed structure, datatypes, and values of an XML document (often called the XML instance document).

A schema is a declarative way to enforce business rules-that is, once declared, the declared rules are enforced not by application code but by standard infrastructure code. Infrastructure elements that parse and validate instance documents against a schema are called validating parsers. An organization or business consortium creates a schema and publishes the schema to a known location. The schema then becomes a contract between transacting parties.

For example, an invoice schema between Flute Bank and its suppliers is an agreement on how invoice-related data will be structured and what the contents of an invoice mean. Once the schema is defined and associated with an XML instance document, a validating parser is able to automatically ensure that the XML document is both well formed and valid (conforms to business rules defined in the schema document) (see Figure A.1). Without XML schemas, the conformity of an XML instance document to business rules must be checked programmatically in every application.

Figure A.1: Role of XML Schema and schema validators

Although not depicted in the Figure A.1, the XML schema for a Flute Bank employee is also an XML document. The vocabulary and grammar of all schema documents are defined in the "schema of schemas": XMLSchema.xsd. All schemas are validated against the schema of schemas, just as the employee XML instance is validated against the employee XML schema. The "schema of schemas" is further explained in the XML Schema "Namespaces" section later in this chapter.

XML schemas have other advantages as well: they provide the metadata for automatic GUI generation, and visual editors (e.g., XML Spy) use them to create smart editors for XML documents, allowing only valid values to be input into an XML document.

The significance of XML Schema to Web services is this: as you have seen in the chapters on SOAP, transactions, and WSDL, all Web service specifications use XML. XML Schema is the most widely adopted validity-constraint mechanism for XML, and a few (not all) Web-service-related specifications require it as the mechanism.

From the 0.6 draft of the IETF XML guidelines document (www.ietf.org/internet-drafts/draft-hollenbeck-ietf-xml-guidelines-06.txt):

"There is ongoing discussion (and controversy) within the XML community on the use and applicability of various validity constraint mechanisms. The choice of tool depends on the needs for extensibility or for a formal language and mechanism for constraining permissible values and validating adherence to the constraints."

Other popular validity constraint mechanisms are RELAX NG (ISO/IEC Document Schema Definition Language) and Schematron.