Abstract

XML Schema is the most popular schema language for XML today. It has been introduced to overcome some of the commonly observed limitations of DTDs, most notably the lack of typing. Simple Types describe content which is not structured by XML markup, which means it describes attribute values and element content. Simple types can be defined by deriving new types from existing types by using type restriction. Complex Types describe element content if this content is using attributes and/or element content other than only character data. Using XML Schema's type concepts, it is easier to represent model-level information in a schema, because type hierarchies can represent model-level specializations.

Bad Names

XML Schema is a language for describing an XML schema.
An XML schema can be defined using XML Schema.
I would like to use XML Schema for my XML schema.

• The two most awkward name choices in the XML arena:
  1. XML Schema, which is simply a XML schema language (among many others)
  2. Open XML, which is simply an XML language for encoding office documents
• Naming things means getting into people's heads
  • pretentious and all-embracing name choices serve a certain purpose
  • a name is just a name, it has no meaning
  • XSD and WXS are two semi-official acronyms for XML Schema

What's Wrong With DTDs?

• DTDs do not support application-level datatypes
  • XML for B2B is very data-centric and needs typing
  • SGML was created for documents where typing was less important
• DTDs do not support any relationships between markup constructs
  • content models cannot be reused
  • attribute lists cannot be reused
  • structural relationships cannot be exploited in the DTD
  • Parameter Entities are used as a hack to work around this limitation
• DTD + XML Namespaces = Bad idea!

Different Levels of Semantics

• XML Schema's simple data type provide some semantics
  • a formerly undescribed attribute can now be described as being a xs:date
  • it can be understood as being a date and inserted into a calendar
  • but what kind of date is it? a birthday? an order date? a shipping date?
  • a question of the context of where the xs:date appears
• XML Schema better supports model-level information
  • however, XML Schema also only captures part of the application semantics
  • an XML Schema is usually better than a DTD, because it contains types
  • types provide information about the basic datatypes being used
  • additional semantics (e.g., different kinds of dates) must be documented elsewhere

Schema-Validation and Applications

Validation and Typing

• XML Schema does two things at the same time:

1. Validation checks for structural integrity (is the document schema-valid?)
   • checking elements and attributes for proper usage (as with DTDs)
   • checking element contents and attribute values for proper values
2. Type annotations make the types available to applications
   • instead of having to look at the schema, applications get the Post-Schema Validation Infoset (PSVI)
   • type-based applications (such as XSLT 2.0) can work on the typed instance

What is a Type?

• A type is a set of values
  • the values can be enumerated (home, mobile, office)
  • the values can be described by extension (intervals, regular expressions)
• DTD have (almost) no types
  • element content is always #PCDATA (any number of any characters)
  • attributes most often are CDATA (any number of any characters)
  • attributes may have enumerated types (but no extensional types)
  • attributes may use ID/IDREF

XML Schema vs. DTD

Document/Data Perspectives

• XML as documents is text interspersed with structure
  • XML captures text structures that support document processing
  • without these structures, the text remains usable (as unstructured text)
  • structure is good, but not indispensable
• XML as data is structure filled with data
  • programmers think about classes and objects, so they need types
  • without structure, data-centric XML is completely useless
  • programmers often view XML as wire format and types as the portal to their objects

What are Simple Types?

• Simple types describe values not structured by XML markup
  • they describe attribute values (date="2006-10-03")
  • they describe element content (<phone>+1-510-6432253</phone>)
• Simple types can be used for elements or attributes
  • XML Schema treats contents in elements and attributes equally
  • simple type libraries can be designed independent of their eventual use
• Simple types are available in three flavors
  • atomic types: one value of one type (one number in some range)
  • union types: one value of a union of types (a number or the string undefined)
  • list types: a whitespace-separated list of values (phone type="home office")

Named vs. Anonymous

• Types can be named or anonymous
  • named types have a name and can be referenced (and thus be reused)
  • anonymous types have no name and can only be used where they are defined

 <xs:element name="home" type="phoneType"/>
 <xs:element name="office" type="phoneType"/>
 <xs:simpleType name="phoneType">
  <xs:restriction base="xs:string">
   <xs:maxLength value="30"/>
  </xs:restriction>
 </xs:simpleType>

 <xs:element name="business">
  <xs:simpleType>
   <xs:restriction base="xs:string">
    <xs:maxLength value="30"/>
   </xs:restriction>
  </xs:simpleType>
 </xs:element>

Type Definitions

• Simple types are sets of values
  • named simple types are sets of values with a name (and thus reusable)
  • anonymous simple types are sets of values defined where they are needed
• Simple types are defined to represent model-level information
  • in most cases, they will have restrictions associated with them
  • they may also simply be tags for semantics (fax and phone numbers share the same value space)
• XML Schema has a library of built-in datatypes
  • ur-types are the conceptual grounding of all types
  • primitive types are the types that are there by definition
  • derived types are based on primitive types
  • users can derive their own types using simple type restriction

Type Hierarchy

Built-In Types

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
 <xs:simpleType name="integer">
  <xs:restriction base="xs:decimal">
   <xs:fractionDigits value="0" fixed="true"/>
  </xs:restriction>
 </xs:simpleType>
 <xs:simpleType name="nonNegativeInteger">
  <xs:restriction base="integer">
   <xs:minInclusive value="0"/>
  </xs:restriction>
 </xs:simpleType>
 <xs:simpleType name="positiveInteger">
  <xs:restriction base="nonNegativeInteger">
   <xs:minInclusive value="1"/>
  </xs:restriction>
 </xs:simpleType>
</xs:schema>

How to Restrict

• Simple types can be derived by restriction
  • the base type must be a simple type
  • the derived type will be a simple type
  • all simple types form a tree, rooted at the anySimpleType
• Restriction are based on facets
  • each restriction can use 0-n facets
  • facets can be refined in further simple type restrictions
  • XML Schema designers should try to restrict types as much as possible

Facets

• Facets define a certain way of restricting a simple type
  • facets are independent, but they may interact (minLength and maxLength)
  • XML Schema defines 12 constraining facets which may be used for restrictions
  • length, minLength, maxLength, pattern, enumeration, whiteSpace, maxInclusive, maxExclusive, minExclusive, minInclusive, totalDigits, fractionDigits
• Facets may be repeated in different levels of the type hierarchy
  • they may only further restrict the facet (e.g., reducing the maxLength)
  • facets apply to all directly or indirectly derived subtypes
  • facets may be fixed (no further restriction is allowed)
• Not all facets are applicable to all types
  • the applicability depends on the primitive type being used

Facet Applicability

Patterns

• Patterns restrict the lexical space of simple types
  • most other facets restrict the value space (e.g., intervals of numbers)
  • in many cases, patterns are useful additions to value-oriented facets
• Patterns are regular expressions
  • they support many common regex constructs and Unicode
  • the language pattern allows de, de-CH, and other tags
  • the pattern checks for lexical correctness, not against a code list

([a-zA-Z]{2}|[iI]-[a-zA-Z]+|[xX]-[a-zA-Z]{1,8})(-[a-zA-Z]{1,8})*

Simple Type Examples

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
 <xs:simpleType name="myIntegerType">
  <xs:restriction base="xs:integer">
   <xs:minInclusive value="10000"/>
   <xs:maxInclusive value="99999"/>
  </xs:restriction>
 </xs:simpleType>
 <xs:simpleType name="stockKeepingUnitType">
  <xs:restriction base="xs:string">
   <xs:pattern value="\d{3}-[A-Z]{2}"/>
  </xs:restriction>
 </xs:simpleType>
 <xs:simpleType name="USStateType">
  <xs:restriction base="xs:string">
   <xs:enumeration value="AK"/>
   <xs:enumeration value="AL"/>
   <xs:enumeration value="AR"/>
   <!-- and so on ... -->
  </xs:restriction>
 </xs:simpleType>
</xs:schema>

Facet Limitations

• Facets limit one dimension of a type's value space
  • using pattern, the lexical space can also be restricted
  • restrictions should be made as specific as possible
  • no limitations are possible beyond the predefined facets
• There is no connection to the context within the document
  • facets cannot make references to other values (e.g., neighboring attributes)
• Additional constraints should be documented
  • documentation enables applications to implement constraint checking
  • other schema languages (like Schematron) may be used to express these constraints

What is a Complex Type?

• Complex types describe the allowed element content
  • they describe what the element may contain (the element's content model)
  • they describe the attributes that an element may have (the element's attribute list)
• Complex types do not define the element name
  • the complex type defines which content is allowed for the element
  • the element definition uses the complex type to define the allowed element content
• Complex types have similar properties to simple types
  • they can be named or anonymous
  • Complex Type Derivation can be used to construct a type hierarchy

Complex Type Example

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
 <xs:element name="billingAddress" type="addressType"/>
 <xs:element name="shippingAddress" type="addressType"/>
 <xs:complexType name="addressType">
  <xs:sequence>
   <xs:element name="name" type="xs:string"/>
   <xs:element name="street" type="xs:string"/>
   <xs:element name="city" type="xs:string"/>
   <xs:element name="state" type="xs:string" minOccurs="0"/>
   <xs:element name="zip" type="xs:decimal"/>
  </xs:sequence>
  <xs:attribute name="country" type="xs:NMTOKEN"/>
 </xs:complexType>
</xs:schema>

Complex Types & Content Types

• Complex types can have different kinds of content
  • simple content refers to simple type content using additional attributes
  • complex content is anything else (anything beyond simple type content)
• Complex Type Derivation heavily depends on this classification

DTD Content Models

• Defining Elements in DTDs uses a compact syntax
  • XML Schema supports the same facilities with a more verbose syntax
  • XML Schemas adds features which DTDs do not support
• DTDs allow elements to be mandatory, optional, repeatable, or optional and repeatable
  • XML Schema allows the cardinality to be specified
• DTDs allow sequences (,) and alternatives (|)
  • XML Schema introduces a (very limited) operator for all groups
• Apart from the syntax, XML Schema content models are not very different

Mixed Content

• DTDs define mixed content by mixing #PCDATA into the content model
  • DTDs always require mixed content to use the form ( #PCDATA | a | b )*
  • the occurrence of elements in mixed content cannot be controlled
• XML Schema defines mixed content outside of the content model
  • the content model is defined like an element-only content model
  • the mixed attribute on the type marks the type as being mixed
• XML Schema mixed content can use all model groups
  • it is possible to constrain element occurrences in the same way as in element-only content
  • in practice, this feature is rarely used (mixed content often is very loosely defined)

 <xs:element name="p" type="mixedType"/>
 <xs:complexType name="mixedType" mixed="true">
  <xs:choice maxOccurs="unbounded" minOccurs="0">
   <xs:element ref="b"/>
   <xs:element name="i" type="xs:string"/>
   <xs:element name="u" type="xs:string"/>
  </xs:choice>
  <xs:attribute ref="class"/>
 </xs:complexType>

Empty Content

• DTDs have a special keyword for empty elements
  • instead of the content model, the keyword EMPTY is used
  • empty elements may still have attribute lists associated with them
• XML Schema empty types are defined implicitly
  • there is no explicit keyword for defining an empty type
  • if a type has no model group inside it, it is empty (it still may have attributes)

Named and Anonymous Types

• Types can be named or anonymous
  • named types can be reused (for elements, attributes, or type derivation)
  • anonymous types can only be used where they are defined
• DTD types are always anonymous (they cannot be reused)

<!ELEMENT person (name, address) >
<!ATTLIST person id ID #REQUIRED >

• DTDs have everything hardcoded
  • complex types are always locally defined
  • elements are always globally defined
  • attributes are always locally defined

Local vs. Global Elements

• Elements can be defined in a type or in the schema
  • local elements can only be used where they are defined
  • global elements can be reused, they can serve as building blocks
• Elements and complex types depend on each other
  • an element is defined by a type, often this will be a complex type
  • a complex type is defined by its contents, which are elements and/or attributes

 <xs:complexType name="mixedType" mixed="true">
  <xs:choice maxOccurs="unbounded" minOccurs="0">
   <xs:element ref="b"/>
   <xs:element name="i" type="xs:string"/>
   <xs:element name="u" type="xs:string"/>
  </xs:choice>
  <xs:attribute ref="class"/>
 </xs:complexType>
 <xs:element name="b" type="xs:string"/>

Reusable Elements

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
 <xs:element name="billingAddress" type="addressType"/>
 <xs:element name="shippingAddress" type="addressType"/>
 <xs:complexType name="addressType">
  <xs:sequence>
   <xs:element name="name" type="xs:string"/>
   <xs:element name="street" type="xs:string"/>
   <xs:element name="city" type="xs:string"/>
   <xs:element name="state" type="xs:string" minOccurs="0"/>
   <xs:element name="zip" type="xs:decimal"/>
  </xs:sequence>
  <xs:attribute name="country" type="xs:NMTOKEN"/>
 </xs:complexType>
</xs:schema>

Attribute Definitions

• DTDs treat attributes as something entirely different from element content
  • they are defined in an ATTLIST, not in the ELEMENT definition

    <!ELEMENT person (name, address) >
    <!ATTLIST person id ID #REQUIRED >

  • they have a special range of Attribute Types as opposed to elements

    <!ATTLIST person id ID #REQUIRED >

• XML Schema overcomes these restrictions only partially
  • Simple Types are used to define attribute (or element) contents
  • attributes are still described as something entirely different from an element's content model
• Attributes could be better integrated into the model
  • RELAX NG treats attributes as part of an element's content model
  • this makes it trivial to have choices of element content and attributes

Reusing Attributes

• DTDs treat attributes as something local to an element
  • attributes are defined in an element's ATTLIST
  • reusing attributes for more than on element requires Parameter Entities
• XML Schema better supports reuse of schema components
  • types can be defined locally (anonymous) or globally (named)
  • elements and attributes can be defined globally or locally
• Globally defined attributes can be reused
  • the attribute definition does not tie it to any occurrence
  • the attribute can then be referenced from an complex type definition

Reusing Attributes (Example)

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
 <xs:element name="p" type="mixedType"/>
 <xs:complexType name="mixedType" mixed="true">
  <xs:choice maxOccurs="unbounded" minOccurs="0">
   <xs:element ref="b"/>
   <xs:element name="i" type="xs:string"/>
   <xs:element name="u" type="xs:string"/>
  </xs:choice>
  <xs:attribute ref="class"/>
 </xs:complexType>
 <xs:element name="b" type="xs:string"/>
 <xs:attribute name="class">
  <xs:simpleType>
   <xs:restriction base="xs:string">
    <xs:enumeration value="comment"/>
    <xs:enumeration value="warning"/>
   </xs:restriction>
  </xs:simpleType>
 </xs:attribute>
</xs:schema>

Definitions

• Many XML Schemas define a vocabulary for a namespace
  • DTDs do not have any support for namespaces
  • XML Schema heavily builds on XML Namespaces
• XML Schema provides support for declaring a vocabulary's namespace

  <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.example.com/">

• Schema-validation can check for proper namespace usage
  • the targetNamespace has to be used in the instance
  • if the namespace does not match, validation cannot succeed

Instances

• The schema defines the targetNamespace of the vocabulary
  • all globally defined elements, attributes, and types are in that namespace
  • the instances must declare and use the namespace to be schema-valid

<html xmlns="http://www.w3.org/1999/xhtml">
 <head>
  <title>Multicolumn Layout in HTML</title>
  <style type="text/css">

• A prefixed name is not the same as a qualified name
  • if there is a default namespace, unprefixed elements are still qualified
• Nasty details about XML Namespaces and attributes
  • the default namespace does not apply to attributes
  • attributes must therefore always be prefixed if they need to be qualified

Name Qualification

• Global elements and attributes have to be used as qualified names
  • this means that they must be referred to by their namespace-qualified name
  • if a default namespace is used, elements are qualified without carrying a prefix
  • since the default namespace does not apply to attributes, they always must be explicitly prefixed
• Local elements and attributes may be used qualified or unqualified
  • this control only applies to locally define elements or attributes
  • the default defined by XML Schema is not a good choice
  • because of how XML Namespaces work, a non-default choice is recommended
• XML Schema allows control over how local names have to be used

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.example.com/" elementFormDefault="qualified" attributeFormDefault="unqualified">

Element = Type + Constraints

• DTDs and XML Schema are mainly about specifying grammars
  • types describe the allowed values using grammars
  • grammar-oriented schemas have some nice properties
• DTD's ID/IDREF allow additional constraints
  • apart from the grammar definition, cross-references in the tree are supported
  • validation checks the integrity of the cross-references, not only the tree
• DTD's ID/IDREF are a very simple mechanism
  • they are always global
  • they also define the type of the attribute (XML names)

Improvements over ID/IDREF

• XML Schema's Identity Constraints improve DTD's ID/IDREF
• Identity constraints are scoped and apply only to a selected set of nodes
  • the constraint applies only to a selected set of nodes (using XPath)
• Identity constraints are evaluated using typed values
  • IDs must be XML names (no numbers allowed)
  • 2 ≟ +00002 should be evaluated based on the type (string or decimal?)
  • XML Schema separates the constraint from the type of the selected nodes
• Identity constraints may select elements or attributes
  • XPaths are used to select the constrained values, they can select elements or attributes
• Multiple fields
  • it is possible to select more than one field for a constraint (phone & area code must be unique)

Types of Identity Constraints

• Uniqueness constraints
  • if there is a field, it must have a unique value among the selected nodes
• Key constraints
  • there must be a field, and it must have a unique value among the selected nodes
• Key reference constraints
  • the field must refer to an existing value in the referred key
  • if the key reference also is constrained by a key, only one reference may use the referred key

Identity Constraint Definitions

• Identity constraints are part of an element definition
• There are three important factors to an identity constraint
  1. location of the identity constraint's definition
  2. the nodes to which the constraint should be applied
  3. the fields which are used to evaluate the constraint
• If the constraint is a key reference constraint, there is a fourth factor
  4. the key constraint that is used for checking the references

Identity Constraint Evaluation

Advanced Identity Constraints

Type Derivation

• XML Schema supports the modeling approach of specialization
  • simple types can be restricted to create more specialized simple types
  • each value of a restricted type is also a valid value of the more general type
• Complex types are combinations of content and attributes
• Specialization of complex types can be done in two ways
  • Complex Type Restriction: more restricted ways of using the content and/or attributes
  • Complex Type Extension: additional content and/or attributes may be used
• Both kinds of complex type derivation can be regarded as specialization
  • Complex Type Restriction: for US persons the country must always be set to US
  • Complex Type Extension: people having an employee number are employees

Removing Choices

• Complex types usually allow variability
  • minOccurs and maxOccurs allow variability in occurrences
  • choice groups allow to choose between a number of alternatives
  • attributes may be flagged as use="optional"
  • simple types allow the individual values to use certain sets of values
• Complex type restriction allows restrictions of all these variations
  • minOccurs and maxOccurs can be made more restrictive
  • alternatives can be removed from choice groups
  • optional attributes can flagged as use="required" or use="prohibited"
  • the simple types of values can be set to more restricted simple types
• The technical way of defining restrictions is cumbersome
  • when the base type changes, the restricted type has to be fixed by hand

Complex Type Restriction (Example)

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
 <xs:complexType name="addressType">
  <xs:sequence>
   <xs:element name="name" type="xs:string"/>
   <xs:element name="street" type="xs:string"/>
   <xs:element name="city" type="xs:string" minOccurs="0"/>
   <xs:choice>
    <xs:element name="state" type="xs:string"/>
    <xs:element name="canton" type="xs:string"/>
   </xs:choice>
   <xs:element name="zip" type="xs:decimal"/>
  </xs:sequence>
  <xs:attribute name="country" type="xs:NMTOKEN"/>
  <xs:attribute name="territory" type="xs:string" use="optional"/>
 </xs:complexType>
 <xs:complexType name="USaddressType">
  <xs:complexContent>
   <xs:restriction base="addressType">
    <xs:sequence>
     <xs:element name="name" type="xs:string"/>
     <xs:element name="street" type="xs:string"/>
     <xs:element name="city" type="xs:string"/>
     <xs:choice>
      <xs:element name="state" type="xs:string"/>
     </xs:choice>
     <xs:element name="zip" type="zipType"/>
    </xs:sequence>
    <xs:attribute name="country" type="xs:NMTOKEN"/>
    <xs:attribute name="territory" type="xs:string" use="prohibited"/>
   </xs:restriction>
  </xs:complexContent>
 </xs:complexType>
 <xs:simpleType name="zipType">
  <xs:restriction base="xs:decimal">
   <xs:totalDigits value="5"/>
  </xs:restriction>
 </xs:simpleType>
</xs:schema>

Processing Restricted Complex Types

• Values of restricted types are values of the base types
  • type restriction is defined so that restricted type values are always base type values
  • code processing a type can be reused to process restricted types
• If there is a well-designed type hierarchy, programming becomes easier
  • simple code can be written to handle the basic types
  • if required, more advanced code can be written for the restricted types
  • in many cases, restriction is more for validation than for processing
• XML Schemas may even use abstract types
  • no element will ever use the addressType
  • concrete elements will only use restricted types
  • there can be code handling the addressType which handles all addresses

Adding Content

• Complex types are element content and attributes
  • extensions can add content, but only at the end of the base content
  • extensions can add attributes (order is not significant for attributes)
• Adding content to existing content may not change the existing content
  • if the content is element only, it has to remain element only
  • if the content is mixed, is has to remain mixed
  • if the content is empty, it may become element only or mixed
  • the reason for these rules is that mixed is a global property of a type
• Adding attributes simply adds these to the list of existing attributes
  • the added attributes may be optional or required

Complex Type Extension (Example)

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
 <xs:complexType name="addressType">
  <xs:sequence>
   <xs:element name="name" type="xs:string"/>
   <xs:element name="street" type="xs:string"/>
   <xs:element name="city" type="xs:string" minOccurs="0"/>
   <xs:choice>
    <xs:element name="state" type="xs:string"/>
    <xs:element name="canton" type="xs:string"/>
   </xs:choice>
   <xs:element name="zip" type="xs:decimal"/>
  </xs:sequence>
  <xs:attribute name="country" type="xs:NMTOKEN"/>
  <xs:attribute name="territory" type="xs:string" use="optional"/>
 </xs:complexType>
 <xs:complexType name="businessAddressType">
  <xs:complexContent>
   <xs:extension base="addressType">
    <xs:sequence>
     <xs:element name="company" type="xs:string"/>
     <xs:element name="position" type="xs:string" minOccurs="0"/>
    </xs:sequence>
    <xs:attribute name="relationship" type="xs:NMTOKEN"/>
   </xs:extension>
  </xs:complexContent>
 </xs:complexType>
</xs:schema>

Processing Extended Complex Types

• Values of extended types are not values of the base types
  • type extension adds content add/or attributes to a type
  • if content is added, it is always added at the end of the base type's content
• If there is a well-designed type hierarchy, programming becomes easier
  • simple code can be written to handle the basic types
  • if that should handle extended types, it must be written to handle extensions
  • handling extensions can be as simple as skipping them
• XML Schemas may even use abstract types
  • no element will ever use the addressType
  • concrete elements will only use extended types
  • code handling extended types can build on code handling the base type

Schema Components

XML Schema Features

• XML Schema allows defining a grammar for XML documents
• Types make it easier to turn a model into a grammar
• Identity constraints enable non-grammar constraints to be expressed
• Some of the things we have not seen:
  • named groups, modularizing schemas, wildcards, substitution groups, ...