XML Schema (XSD) – Part III

XML Foundations [./]
Fall 2013 — INFO 242 (CCN 41613)

Erik WildeUC Berkeley School of Information, UC Berkeley School of Information
2013-10-07

[http://creativecommons.org/licenses/by/3.0/]

This work is licensed under a CC
Attribution 3.0 Unported License [http://creativecommons.org/licenses/by/3.0/]

Contents E. Wilde: XML Schema (XSD) – Part III

Contents

2Abstract
1 Names and Namespaces
- 4Definitions
- 5Instances
- 6Name Qualification
2 Identity Constraints
- 8Element = Type + Constraints
- 9Improvements over ID/IDREF
- 10Types of Identity Constraints
- 11Identity Constraint Definitions
- 12Identity Constraint Evaluation
- 13Advanced Identity Constraints
3 Complex Type Derivation
- 15Types in XSD
- 16Type Derivation
- 3.1 Complex Type Restriction
  - 18Removing Choices
  - 19Complex Type Restriction (Example)
  - 20Processing Restricted Complex Types
- 3.2 Complex Type Extension
  - 22Adding Content
  - 23Complex Type Extension (Example)
  - 24Processing Extended Complex Types
4 Conclusions
- 26XSD Features
- 27Schema Components

E. Wilde: XML Schema (XSD) – Part III

(2) Abstract

XSD allows greater flexibility in defining constraints on intra-document references than the ID/IDREF construct of DTDs. XSD's Identity Constraints are scoped, typed, and can be used for elements or attributes. They are more powerful that the DTD's limited ID/IDREF mechanism, but still lack sufficient generality to support a really wide set of model constraints to be expressed. XSD complex types can be derived by restriction or extension. Complex type restriction defines the restricted type to be a more restricted version of the base type. Complex type extension make it possible to extend the base type by either adding attributes or contents (only by appending new content to the content model). Complex type derivation allows XSD to express type hierarchies of complex types, which can be aligned with more or less specialized code for processing instances of these types.

Names and Namespaces

Outline (Names and Namespaces)

Names and Namespaces [3]
Identity Constraints [6]
Complex Type Derivation [8]
1. Complex Type Restriction [3]
2. Complex Type Extension [3]
Conclusions [2]

Names and Namespaces E. Wilde: XML Schema (XSD) – Part III

(4) Definitions

Many XSDs define a vocabulary for a namespace
- DTDs do not have any support for namespaces
- XSD heavily builds on XML Namespaces [XML Namespaces]

XSD 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

Names and Namespaces E. Wilde: XML Schema (XSD) – Part III

(5) 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">

multicol.html (line 2-5)

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

Names and Namespaces E. Wilde: XML Schema (XSD) – Part III

(6) 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 XSD is not a good choice
- because of how XML Namespaces work, a non-default choice is recommended
XSD 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">

Identity Constraints

Outline (Identity Constraints)

Names and Namespaces [3]
Identity Constraints [6]
Complex Type Derivation [8]
1. Complex Type Restriction [3]
2. Complex Type Extension [3]
Conclusions [2]

Identity Constraints E. Wilde: XML Schema (XSD) – Part III

(8) Element = Type + Constraints

DTDs and XSD are mainly about specifying grammars
- types describe the allowed values using grammars
- grammar-oriented schemas have some nice properties
DTD's ID/IDREF [Document Type Definition (DTD); ID/IDREF (1)] 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)

Identity Constraints E. Wilde: XML Schema (XSD) – Part III

(9) Improvements over ID/IDREF

XSD'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?)
- XSD 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)

Identity Constraints E. Wilde: XML Schema (XSD) – Part III

(10) 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 Constraints E. Wilde: XML Schema (XSD) – Part III

(11) 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
1. the key constraint that is used for checking the references

Identity Constraints E. Wilde: XML Schema (XSD) – Part III

(12) Identity Constraint Evaluation

Identity Constraints E. Wilde: XML Schema (XSD) – Part III

(13) Advanced Identity Constraints

identity-constraints++.png

Complex Type Derivation

Outline (Complex Type Derivation)

Names and Namespaces [3]
Identity Constraints [6]
Complex Type Derivation [8]
1. Complex Type Restriction [3]
2. Complex Type Extension [3]
Conclusions [2]

Complex Type Derivation E. Wilde: XML Schema (XSD) – Part III

(15) Types in XSD

Simple Types [XML Schema (XSD) – Part I; Simple Types (1)] are used to model non-markup values
Simple Type Restriction [XML Schema (XSD) – Part I; Simple Type Restriction (1)] is used to define simple user types
Complex Types [XML Schema (XSD) – Part II; Complex Types (1)] are used to model markup structures
Models often use generalization and specialization
- not all models use this modeling technique
- OO methods have made this very popular (UML is OO)
Complex Type Derivation [Complex Type Derivation (1)] is used to represent model hierarchies
- in theory, this could be used by generalized and specialized code
- in practice, the connection between XSD and code is too weak to be robust

Complex Type Derivation E. Wilde: XML Schema (XSD) – Part III

(16) Type Derivation

XSD 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 [Complex Type Restriction (1)]: more restricted ways of using the content and/or attributes
- Complex Type Extension [Complex Type Extension (1)]: additional content and/or attributes may be used
Both kinds of complex type derivation can be regarded as specialization
- Complex Type Restriction [Complex Type Restriction (1)]: for US persons the country must always be set to US
- Complex Type Extension [Complex Type Extension (1)]: people having an employee number are employees

Complex Type Restriction

Outline (Complex Type Restriction)

Names and Namespaces [3]
Identity Constraints [6]
Complex Type Derivation [8]
1. Complex Type Restriction [3]
2. Complex Type Extension [3]
Conclusions [2]

Complex Type Restriction E. Wilde: XML Schema (XSD) – Part III

(18) 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 E. Wilde: XML Schema (XSD) – Part III

(19) 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>

complex-restriction.xsd

Complex Type Restriction E. Wilde: XML Schema (XSD) – Part III

(20) 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
XSDs 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

Complex Type Extension

Outline (Complex Type Extension)

Names and Namespaces [3]
Identity Constraints [6]
Complex Type Derivation [8]
1. Complex Type Restriction [3]
2. Complex Type Extension [3]
Conclusions [2]

Complex Type Extension E. Wilde: XML Schema (XSD) – Part III

(22) 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 E. Wilde: XML Schema (XSD) – Part III

(23) 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>

complex-extension.xsd

Complex Type Extension E. Wilde: XML Schema (XSD) – Part III

(24) 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
XSDs 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

Conclusions

Outline (Conclusions)

Names and Namespaces [3]
Identity Constraints [6]
Complex Type Derivation [8]
1. Complex Type Restriction [3]
2. Complex Type Extension [3]
Conclusions [2]

Conclusions E. Wilde: XML Schema (XSD) – Part III

(26) XSD Features

XSD allows defining a grammar for XML documents
Identity constraints enable non-grammar constraints to be expressed
XSD identity constraints are more powerful than the DTD ID/IDREF concept
Only a subset of structural constraints can be expressed in XSD
XSD 1.1 introduces the concept of assertions (XPath-based constraints)
Types make it easier to turn a model into a grammar
Some of the things we have not seen:
- named groups, modularizing schemas, wildcards, substitution groups, …

Conclusions E. Wilde: XML Schema (XSD) – Part III

(27) Schema Components

Schema Components

2013-10-07 XML Foundations [./]
Fall 2013 — INFO 242 (CCN 41613)