WSDL-related XML Schema language basics

The XML Schema Definition Language (XSD) has become a central and very common part of XML and Web services architectures. The hierarchical structure of XML documents can be formally defined by creating an XSD schemahence an XML document is considered an instance of its corresponding schema. Further, the structure established within an XSD schema (Figure 13.3) contains a series of rules and constraints to which XML document instances must comply for parsers and processors to deem them valid.

Figure 13.3. An XSD schema document.

The fundamental data representation rules provided by XSD schemas are related to representing data according to type. As with data types used in programming languages, XSD schemas provide a set of non-proprietary data types used to represent information in XML document instances.

The data types supported by XSD schemas are extensive, but they do not always map cleanly to the proprietary types used by programming languages. Therefore, many environments must go through a mapping process to select the XSD schema types best suited to represent data originating from or being delivered to proprietary application logic and data sources.

XSD schemas can exist as separate documents (typically identified by .xsd file extensions), or they may be embedded in other types of documents, such as XML document instances or WSDL definitions. XML document instances commonly link to a separate XSD schema file so that the same schema can be used to validate multiple document instances. WSDL definitions can import the contents of an XSD file, or they also can have schema content embedded inline.

Because almost all XML and Web services specifications are themselves written in XML, XSD schemas have become an intrinsic part of XML data representation and service-oriented architectures. Regardless of whether you explicitly define an XSD schema for your solution, your underlying processors will be using XSD schemas to execute many tasks related to the processing of XML documents through Web services. (The role of XSD schemas within SOA is explained further in the XML Schema and SOA section in Chapter 14.)

"Elements" vs. "Constructs"

Each of the specifications we explore in this and subsequent chapters provides a markup language that is expressed as an XML dialect. This means that the language itself is written in XML and is comprised of XML elements. Our focus is on describing key elements that provide features relevant to the topics discussed in this book. Sometimes we refer to language elements as constructs. A construct simply represents a key parent element likely to contain a set of related child elements. Therefore we use this term to communicate that the element we are discussing will contain additional elements that form a block of XML.

13.2.1. The schema element

The schema element is the root element of every XSD schema. It contains a series of common attributes used primarily to establish important namespace references. The xmlns attribute, for example, establishes a default namespace on its own, or can be used to declare a prefix that acts as an identifier to qualify other elements in the schema.

The http://www.w3.org/2001/XMLSchema namespace always is present so that it can be used to represent content in the schema that originates from the XSD specification and the elements in the schema document itself. This allows processors to distinguish native XSD schema content from user-defined content.

Example 13.1. The most basic form of schema declaration.

Other important attributes include targetNamespace, used to assign a namespace to the custom elements and attributes declared in the schema document, and the element-FormDefault attribute, which when set to a value of "qualified," requires that all elements in the XML document be associated with their corresponding namespace.

13.2.2. The element element

Using this element, you can declare a custom element that is then referenced by its name within an XML document instance.

For example, the following element declaration in an XSD schema:

Example 13.2. An element declaration in an XSD schema.

...will be represented within an XML document as follows:

Example 13.3. The usage of this element in an XML document instance.

12345

...where the value in between the opening and closing InvoiceNumber tags is required to be an integer.

The type attribute of an element can be set to one of the predefined data types established by the XML Schema specification, or it can be assigned a complex type, as explained next.

13.2.3. The complexType and simpleType elements

With a complexType you can group elements and attributes into a composite type that can be used to represent a set of related data representations. The following example groups two elements named ID and WeeklyHoursLimit into a complexType named EmployeeHours.

Example 13.4. A complexType containing two element declarations.

<complexType name="EmployeeHours">