5.2.1 Value Space

The type system of XML Schema makes a clear distinction between value space and lexical space. While the value space consists of an abstract collection of valid values for a data type, the lexical space contains the lexical representation of these values—that is, the tokens as they appear in the XML document. Take for example an integer. The value of integer 5 is always the same; the lexical representation, however, can differ: 5, 005, five, V, ***, and so on.

5.2.2 Lexical Representations and Canonical Representation

The XML Schema recommendation defines which lexical representations are valid for a given data type. In some cases, there is only one possible representation, but in many cases, various kinds of lexical representations are allowed. Take for example data type boolean: XML Schema allows the representation “true” and “false” but also the representation “1” (for “true”) and “0” (for “false”).

In such cases where XML Schema allows several lexical representations, one representation is designated as the canonical representation. For data type boolean this is the representation “true” or “false.” Canonical representations are important when we want to compare two document instances for equality: It is first necessary to convert both documents into the canonical form, before they can be compared by character string comparison. Section 4.3 already discussed the W3C recommendation “Canonical XML” [Boyer2001]. Because XML data types are not covered by this recommendation, the XML Schema specification explicitly defines the canonical formats of its own data types.

5.2.3 Fundamental Facets

XML Schema defines basic data types in a very systematic way. The properties of data types are classified in so-called facets. Each facet describes a specific aspect of a data type, such as equality, cardinality, and length. Again, these facets are classified into two categories:

XML Schema defines the following fundamental facets:

5.2.4 Built-in Primitive Data Types

Using fundamental facets, XML Schema defines a set of built-in primitive data types. Table 5.1 lists these data types with their respective lexical representations. Canonical representations are printed in bold, and the other representations are followed by the reason why they are not canonical. The table also lists which constraining facets may be applied to each data type in order to derive other data types from it (see Section 5.2.7).

5.2.5 Constructed Types

XML Schema derives additional built-in data types from these primitive data types. This is done with a simpleType declaration.

XML Schema uses three methods for constructing built-in data types.¹ These methods can also be employed by schema authors to construct their own data types.

The application of these methods by XML Schema to the built-in data types results in a rather large hierarchy of built-in derived data types, which are listed in Section 5.2.8. In terms of the theory of regular types, restrictions create subtypes (see Section 1.7.4), while extensions create supertypes.

When defining user-defined types, users have the ability to inhibit further type construction. This is done with the final attribute, which can take one of the following values: #all, list, union, restriction. This allows inhibiting further construction by any method (#all) or by a specific method.

5.2.6 Extending Data Types by List

Most data types can be extended to a list of this base data type. Within an XML element or attribute instance, the values of a list are separated by whitespace. Therefore, this extension method can only be applied to data types that do not allow whitespace in the lexical representation. In particular, it is not possible to nest lists.

In contrast to the type system of Relax NG (see Chapter 7), XML Schema does not allow the construction of lists with members of different data types.

The following example shows how we can define a vector consisting of an arbitrary number of double-precision floating-point numbers:

A possible instance of such a type could look like the following:

Extension by list defines a supertype of the base data type. The value space of the base data type is just a subset of the value space of the list data type (list length = 1).

5.2.7 Restricted Data Types

In contrast, constructing a data type by applying constraints results in a subtype of the base data type, because the value space of the new data type is restricted; that is, it is a subset of the value space of the base data type.

XML Schema classifies the constraints that can restrict a data type into constraining facets. Each facet controls a different aspect of a data type, for example, the total number of digits or the number of fractional digits for a decimal data type. As shown earlier in Table 5.1, each primitive data type defines which constraining facet may be applied to it.

The following constraining facets are available in XML Schema:

5.2.8 Built-in Constructed Data Types

By applying the constraining facets explained above and by applying list extensions, XML Schema defines a hierarchy of built-in constructed data types (see Table 5.2 and Figure 5.2). Built-in data types belong to the XML Schema namespace, represented here with prefix “xs:”.

5.2.9 The Hierarchy of Built-in Primitive and Constructed Data Types

The built-in primitive data types listed in Section 5.2.4 and the built-in constructed data types listed in Section 5.2.8 establish a hierarchy of data types as shown in Figure 5.2. Constructed data types are obtained from primitive data types and other constructed data types by restriction and list extension. Please note that these operations do not establish a hierarchy in terms of subtype and supertype. While type restriction always results in a subtype of the base type, list extension always results in a supertype of the base type. This is the reason why we use the term constructed data type in contrast to derived data type as used in the XML Schema Recommendation, Part Two. The formal definition of derived in Part One of the recommendation does not allow for type extension by list or union.

5.2.10 Union Types

With the union operation, it is possible to combine disparate data types in a single data type. The new data type is a supertype to all the contributing member data types: Its value space is the union of the value spaces of all contributing member data types. The member data types can be either referenced by name in the memberTypes attribute or defined locally using simpleType declarations within the union element.

In the following schema fragment, a string data type tISBN is defined. The pattern facet restricts valid strings to the typical ISBN patterns, such as 0-646-27288-8. (For an explanation of the pattern syntax, see the appendix.) A second data type, tProductNo, is defined next, representing custom product numbers. These product numbers start with “9-” followed by two groups of three to five decimal characters, followed by a single decimal character, for example, 9-234-9393-0.

We can then use these two type definitions to construct a union type tISBNorProductNo allowing both patterns. We could use this combined data type for a catalog containing books and other products.

In this example the patterns of the two member types tISBN and tProductNo are chosen in such a way that their lexical value domains overlap. In such cases the sequence of the member types given in the union clause matters: An XML Schema-aware processor would first try to match an instance string to the tISBN pattern, and if that failed, to the tProductNo pattern. However, individual instances may enforce the usage of a specific member type via the xsi:type attribute (see Section 6.2.4).

5.2.11 User-Defined Data Types

As mentioned in Section 5.2.5, it is possible for users to construct their own data types from built-in data types. Let’s look at an example. We want to declare a schema for asset jazzMusician defined in Figure 3.5. We choose to represent the property kind as an attribute. Since only three values are allowed, we want to declare the attribute accordingly, restricting its value range to instrumentalist, jazzSinger, and jazzComposer. We can achieve this with the following definition:

What we do is declare a simple data type on the fly. This new anonymous data type is only used for the attribute with the name “kind” and is derived from the built-in data type xs:NMTOKEN by restriction. We then use three occurrences of the xs:enumeration facet to define the three possible values.

Similarly, we could define an element duration (for the duration property of asset track):

Here, we use a restricted form of the built-in data type xs:duration in that we only allow durations smaller or equal to 77 minutes.

1. The root element of a document is defined on the schema level via an element definition.

2. This root element has a complex type.

3. Complex type declarations combine other (global and local) elements that again may have a complex type, or otherwise have a simple type.

4. This combination is achieved via model groups consisting of sequences, choices, or bags.

5. Particles can further constrain model groups by introducing cardinality constraints.

 The first element definition specifies the root element for all document instances.

 Subsequent element declarations on the schema level are used to specify global elements. They may or may not appear in instance documents, and will certainly not appear in root position. Instead, this set of element definitions acts as a kind of local library for element definitions.

 Particles define child element structures.

 Simple content relates to a simple data type that can be extended by local definitions.

 Complex content relates to an earlier defined complex data type or to the built-in data type xs:anyType. This complex type can then be restricted by local definitions.

 an element declaration (see Section 5.3.2)

 a wildcard (see Section 5.3.15)

 a model group

Model Groups

Model groups are similar to DTD model groups, but the syntax is completely different and there is a new connector. Model groups can be constructed using three kinds of connectors:

The xs:sequence connector has the following child nodes:

This connector has the same semantics as the, connector in an XML DTD or the, operator in a regular expression (see Section 1.7. It specifies an ordered sequence of elements—that is, it requires that instance documents adhering to this schema always use elements in the prescribed sequence. Given the schema fragment

the following instance fragment is valid

The xs:all connector has the following child nodes:

This connector has no equivalent in the XML DTD, but it has the same semantics as the & connector in an SGML DTD or the & operator in a regular expression (see Section 1.7. It does not require a particular order of elements in the document instance—it specifies a bag of elements. Given the schema fragment

both of the following instance fragments are correct:

As you can see, XML Schema makes it easy to specify unordered sequences. With the DTD we had to resort to specifying alternatives of all possible permutations of the child elements, a quite laborious process.

The following example is invalid for two reasons: (1) The all connector is the child of an xs:sequence connector, and (2) the all connector contains an xs:choice connector.

The xs:choice connector has the following child nodes:

This connector has the same semantics as the | connector in an XML DTD or the | operator in a regular expression (see Section 1.7. It specifies alternatives of elements—that is, it requires that the instance documents use only one element out of the defined list. Given the schema fragment

the following instance fragments are possible:

But this is not possible:

Here is the equivalent DTD:

The xs:sequence and xs:choice connectors can be nested to create complex element structures. For example:

Here is the equivalent DTD fragment (ignoring type declarations):

Here, we have defined an alternative that consists either of a sequence of from and to elements, or of a bag of location and time elements. Note that we have resolved the bag into two xs:sequence connectors, as it is not allowed to define an xs:all connector inside an xs:choice connector.

The following instance fragments would be possible:

Note: For a discussion of nondeterministic choice groups, see Section 5.3.18.

5.3.4 Cardinality Constraints

Cardinality constraints can be applied to particles. A particle is either an element, a wildcard (see Section 5.3.15), or a model group:

Obviously, the following constraints apply for the values of minOccurs and maxOccurs:

A special “unbounded” value for maxOccurs allows an unlimited number of occurrences. For both minOccurs and maxOccurs the default value is 1; so, if neither is specified, an element or particle has to appear once and only once. Compared to the cardinality operators available in DTDs (+, ?, *), the combination of minOccurs and maxOccurs offers advanced functionality (see Table 5.3).

For example, this album has exactly one title and one or several tracks:

Here is the equivalent DTD fragment:

5.3.5 Default Values and Fixed Values

DTDs allow us to define default values and fixed values for attributes. In contrast to DTDs, XML Schema allows us to define default values and fixed values for elements, too. This is done via the attributes default and fixed. For example:

Note that these schema declarations modify—just like the DTD default and fixed values—the content of the instance document. The content seen by a schema-aware application is different from the content seen by a non-schema-aware application parser.

5.3.6 Mixed Content

By default, an element of complex type must only contain attributes and child elements, but no other content, such as text. To allow mixed content—content consisting of child elements and text—we specify the attribute mixed=“true” in a complexType declaration. This method of declaring mixed content for an element is superior to the mixed content declaration in a DTD: We can control not only the number and types of child elements but also their sequence, with the help of an xs: sequence connector. If we do not want to control the sequence, we just use an xs:all connector instead. In fact, we may use an arbitrary complex particle consisting of several nested connectors in connection with the mixed declaration.

The following example instance document shows a typical mixed content element description:

We can define such an element type with the following specification:

Here is the equivalent DTD fragment (ignoring type declarations):

In this example, we have defined a header consisting of album title, performer, and number of tracks, followed by a repeating group consisting of track number and track title. All the defined elements must appear in the prescribed order, but because we have specified mixed=“true”, arbitrary text may be interspersed between the elements. Without this declaration the document instance fragment would have to look like this:

5.3.7 Simple Content

Simple content definitions refer to existing simple data types, as discussed in Section 5.2 (built-in or user defined), via an extension or restriction clause. They are usually used to define leaf elements that may contain attributes (see Section 5.3.11).

Here is an example of a simple content definition:

5.3.8 Complex Content

Complex content definitions refer to existing complex data types (user defined or the only built-in complex data type, xs: anyType) via an extension or restriction clause. They are usually used to exploit existing complex type definitions (see also Section 6.2 and to define empty elements (see Section 5.3.10). A type extension can be used to add extra particles and/or attributes to a base type.

Given the following type definition,

we add an optional mode element to the complex type definition named tPeriod:

The result would be equivalent to the following type definition:

Because the new element is optional (minOccurs=“0”), the definition covers all instances of the original type tPeriod, too. If the new element were not defined as optional, the extension would not be a supertype, because the new instance set would not cover the instances of the original type definition.

Note that additional elements are always added at the end of a child element sequence. XML Schema does not provide a way to specify a particular position where a new element should be inserted.

In contrast, the restriction clause can be used to add constraints to a component. Given the original type definition,

the following definition describes a subset of the original instance set (only those names with a single first name and no middle name):

Here, the definition of maxOccurs=“1” is essential because we wish to override the maxOccurs=“unbounded” value.

Actually,the original type definition of

is only an abbreviated form of

Any complex type in XML Schema is a restriction of the only built-in complex type in XML Schema: xs: anyType.

5.3.9 Type Hierarchies

Extension and restriction applied on complex elements result in type definition hierarchies. This should not be misunderstood as a type hierarchy in terms of subtypes and supertypes. Although deriving a complex type A from another complex type B by restriction always results in a true type hierarchy (A being a subtype of B), this cannot be said for type extension. A type obtained by extension is a supertype of the original type only if the added features (elements and attributes) are optional (minOccurs=“0”). This is a must if we want to keep the extended schema compatible with existing document instances. Table 5.4 shows under which conditions a type derivation results in a subtype/supertype relation.

On the other hand, many supertypes cannot be derived by type extension. For example, it is not possible to insert an optional child element into a sequence of elements at any position other than the end of the sequence. It is also not possible to add alternatives to elements (that is, replace an element with a choice group).

5.3.10 Empty Elements

Unlike the DTD, XML Schema does not have an explicit notation for empty elements. Instead, the complex content clause can be used for that purpose:

We use the built-in complex type xs: anyType as a base type. We restrict this generic base type to the two attributes title and duration. These definitions result in valid instance fragments such as

As we saw in Section 5.3.8, we can abbreviate this restriction to xs:anyType with the following, preferred construct:

Here is the equivalent DTD (ignoring type declarations):

The same element without attributes

would have the following definition:

This can be abbreviated to

Here is the equivalent DTD:

5.3.11 Attributes

Attributes can be added to all content models: particles, simple content, and complex content. Attributes are defined with the xs:attribute clause.

This clause always contains the definition of the attribute name. Optionally, it can define a type (simple types only) and can contain a use clause and a default or fixed value definition. The use clause can have the values required, optional, and prohibited.

Here is the equivalent DTD fragment (ignoring type declarations):

In this example, we have defined duration as an attribute of track. The type was set to the built-in type xs:duration and the use clause to required, meaning that this attribute must be specified in instance documents. A valid instance of this element would be

If a type has multiple attributes, the sequence of their definition does not matter, as the attribute nodes of an element form an unordered set (see Section 4.2.4).

Unlike elements, attributes cannot be placed into model groups. The consequence is that we do not have the ability to define elements with mutually exclusive attributes. For example, we might want to define an element person that either has an attribute age or an attribute birthDate. The only option is to define a choice group with two local person elements: one with the attribute age, the other with the attribute birthDate—or even better, to implement both birthDate and age as elements! In Chapter 7 we will see how Relax NG deals with this problem.

5.3.12 Global and Local Types

Both simple types and complex types can be defined on a global level, that is, on the schema level. Such types must be named. This makes it possible to refer to these type definitions when they are used locally. For example,

or

Typically, we define global types when these type definitions are used in several places. We can refer to such type definitions in element definitions and in extension and restriction clauses:

or

or

Global types can be defined as abstract using the clause abstract=“true”. Such types cannot be used for type designation in element definitions, but can only be used to derive other types via extension or restriction. This can be done either within the schema or in the document instance with an xsi:type declaration (see Section 6.2.4).

On the other hand, it is possible to declare a global type as final using the attribute final. This attribute may specify “restriction”, “extension”, or “#all” as a value. If “restriction” is specified, it is not possible to derive other types by restriction. Similarly, “extension” means it is not possible to derive other types by extension, and “#all”, to derive other types by any method.

5.3.13 Global Elements and Attributes

Similar to types, elements and attributes may also be defined on a global level. Global elements and attributes are defined on the schema level following the definition of the document root element. Again, the definition of global elements and attributes makes sense when we want to refer to this definition from several places.

In the following schema we define a global element title after the definition of root element jazzMusician:

When we want to reuse this definition we simply use an element reference like this:

Global definition is the only way to define an element in a DTD. This has drawbacks: It is impossible to define elements with the same name but of different types in different contexts.

5.3.14 Recursive Structures

Global definition of elements is one way in XML Schema to define recursive element structures. For example,

defines a recursive tree of part elements. Because the child element definition refers to the containing element, the containing element must be defined as a global element.

Here is the equivalent DTD fragment (ignoring type declarations):

This technique has a disadvantage: It is not possible to define context-specific recursive element structures. For example, if we want two different part trees—one allowing mixed content, the other not allowing mixed content—and we want to use them in the same document, we have a problem. However, it is relatively easy to define context-specific recursions by using the group construct, discussed in detail in Section 6.2.2. Groups are defined on a global level and can refer to themselves and thus establish recursive structures. Nothing stops us from defining several recursive groups with different layouts and referencing them from context-specific but equally named elements:

Here, we have defined two recursive groups gDetailedListPart and gShortListPart. Note that element productNo is defined as a global element because it has an identical definition in both groups. We can now set up a root element containing two different lists in different contexts, but both lists are constructed from elements with tag part (see Figure 5.4).

Used in this way, groups work similarly to non-terminal symbols in grammars—their names do not appear in instance documents. Consequently, by using group constructs, we should be able to express any schema that can be described by a regular grammar. This is not possible with DTDs!

Here is a valid instance document. (For an explanation of the namespace attributes in the xs:schema clause, see Section 6.1.)

XML Schema wouldn’t be XML Schema if it did not offer at least two solutions to a problem. Another way to define recursive structures in XML Schema is via global complex types. We want to create two part lists—one containing part elements with mixed content, the other containing part elements without mixed content. To do so we define two different types tPart and tPartMixed that introduce part elements of different types locally. These part elements refer recursively to the previously defined type declarations.

Here is the definition of a recursive part structure without mixed content:

The definition for the recursive part structure with mixed content looks quite similar:

We can then use both type definitions to define local part elements that are recursive but have a different type (see Figure 5.5):

Now we can define a document instance that can contain both types of part elements nested in unlimited depth:

5.3.15 Wildcards

A wildcard (an element or attribute of no further specified content) can be declared with the XML Schema elements <xs:any/> or <xs:anyAttribute/>.

Using wildcards allows for the inclusion of elements and attributes from foreign schemata and namespaces (see Section 6.1.3). In this way, sections of XHTML, SVG, RDF, or other content could be included in a document. For example:

The attributes namespace and processContents will be explained in Section 6.1.3.

5.3.16 Nullability

DTDs only support the concept of optional elements: An element is either present or absent. Besides allowing optional elements (with minOccurs=“0”), XML Schema introduces a new concept. Instance elements can be set to “nil” by specifying the attribute xsi:nil=“true”. (Here, xsi: denotes the namespace prefix for XML Schema Instances http://www.w3.org/2001/XMLSchema-instance.) In the schema, the attribute

declares whether an element is nillable, or not (the default value is “false”). Nilled elements must not have any content, but they are allowed to have attributes!

With the following schema fragment,

we allow things like colored null values:

Exciting!

Note that a nilled element is a new concept: It is neither an absent element (defined via minOccurs=“0”) nor an empty element (see Section 5.3.10).

In my opinion, the concept of nilled elements is of limited value. It was introduced to improve the compatibility of XML with certain relational database products. However, mapping, for, example, a nullable SQL field to a nillable XML element may work for a specific application, but it is not a general solution. Traditionally, in many applications nullable database fields are already mapped to optional XML elements. So relational null values already have a defined representation in XML (an optional element or attribute). To represent the new nillable elements in object-oriented or relational data models would therefore require a new representation in these applications.

However, the concept makes sense if we wish to express different flavors of nothingness. A value may be absent for different reasons: It could be absent because it represents real nothingness (such as a person without a middle name), because the document author did not know the value (middle name exists, but is unknown), or it could be absent for some technical reasons (server breakdown, for example). These reasons could be coded into the attributes of a nilled element so that appropriate action can be taken.

5.3.17 Uniqueness, Keys, Reference

Similar to the DTDs, XML Schema provides built-in data types ID and IDREF for modeling cross-references between document elements. However, the main purpose of these data types is to provide backward compatibility with existing XML documents.

XML Schema introduces a more flexible concept for keys, key references, and uniqueness with the key, keyref, and unique clauses. These are not hampered by the inherent restrictions of the DTD key concept:

5.3.18 Deterministic Types

Appendix E of the second edition of the XML 1.0 Recommendation notes that content models should be deterministic (unambiguous). This requirement exists for the purpose of compatibility with SGML. SGML parsers may flag a nondeterministic schema as ambiguous. XML Schema also requires content models such as choice groups and all groups to be deterministic (Unique Particle Attribution).

A content model is deterministic if all particles defined in the model can be reduced to a deterministic regular expression (see Section 1.7.6). A regular expression is deterministic if at each choice point it is possible to decide which branch to take without having to look ahead. Let’s look at an example:

This type definition is not deterministic because both choice branches begin with the same elements. However, the same type can be easily expressed in a deterministic (and more compact) way:

The Unique Particle Attribution is subject to an ongoing debate. The question is: What is more desirable, efficient parsers or easier schema authoring? Arguably, if somebody should suffer, it should be the machine and not the human. But nondeterminism can cause the parser to suffer very much, indeed, as a look-ahead may stretch across several megabytes. And then it is the end user who suffers because of unacceptable response times.

It is not always possible to make a definition deterministic. The following schema was written to describe a small orchestra consisting of either seven saxophone players or three guitarists. It violates the Element Declarations Consistent constraint:

This structure is nondeterministic because both branches begin with a musician tag. There is no way we could refactor this structure into an equivalent nondeterministic structure. In XML Schema, the above schema is illegal: Using an element (musician) with different type declarations within the same choice clause is not allowed. In such cases we are required to change the document structure, for example, to rename the musician elements as saxophonist and guitarist, or to use a different namespace for each musician element.