XSD – Part I

XML Foundations [./]
Fall 2011 — INFO 242 (CCN 42596)

Ray LarsonUC Berkeley School of Information, UC Berkeley School of Information
2011-09-06

[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 R. Larson: XSD – Part I

Contents

2Abstract
3Bad Names
4What's Wrong With DTDs?
5Different Levels of Semantics
6Schema-Validation and Applications
7Validation and Typing
8XSD Syntax
1 XSD Types
- 10What is a Type?
- 11XSD vs. DTD
- 12Document/Data Perspectives
2 Simple Types
- 14What are Simple Types?
- 15Named vs. Anonymous
- 16Type Definitions
- 17Type Hierarchy
- 2.1 Simple Type Restriction
  - 19Built-In Types
  - 20How to Restrict
  - 21Facets
  - 22Facet Applicability
  - 23Patterns
  - 24Simple Type Examples
  - 25Facet Limitations
3 Conclusions
- 27Typed XML Content

R. Larson: XSD – Part I

(2) Abstract

The XML Schema Definition Language (XSD) 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.

R. Larson: XSD – Part I

(3) 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
- XSD and WXS are two semi-official acronyms for XML Schema
Good news: XML Schema has been renamed [http://dret.typepad.com/dretblog/2008/06/new-w3c-drafts-xsd-rdfa.html] (after being renamed [http://dret.typepad.com/dretblog/2007/08/xml-schema-11-x.html])
- XSD now is the official acronym for the XML Schema Definition Language
- (very officially, this name change affects version 1.1 of the language only …)

R. Larson: XSD – Part I

(4) 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 [Document Type Definition (DTD); Parameter Entities (1)] are used as a hack to work around this limitation
DTD + XML Namespaces = Bad idea!

R. Larson: XSD – Part I

(5) Different Levels of Semantics

XSD's simple data type provide some semantics
- a formerly undescribed attribute can now be described as being a 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 date appears
XSD better supports model-level information
- however, XSD also only captures part of the application semantics
- XSD is usually more specific 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

R. Larson: XSD – Part I

(6) Schema-Validation and Applications

R. Larson: XSD – Part I

(7) Validation and Typing

XSD does two things at the same time:

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
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

R. Larson: XSD – Part I

(8) XSD Syntax

XSD Types

Outline (XSD Types)

XSD Types [3]
Simple Types [11]
1. Simple Type Restriction [7]
Conclusions [1]

XSD Types R. Larson: XSD – Part I

(10) 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 [Document Type Definition (DTD); ID/IDREF (1)]

XSD Types R. Larson: XSD – Part I

(11) XSD vs. DTD

	DTD	XSD
Concepts	some conceptual model (formal/informal)
Types	ID/IDREF and (#P)CDATA	Hierarchy of Simple and Complex Types
Markup Constructs	Element Type Declarations <!ELEMENT order …	Element Definitions <xs:element name="order"> …
Instances (Documents)	<order date=""> [ order content ] </order>

XSD Types R. Larson: XSD – Part I

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

Simple Types

Outline (Simple Types)

XSD Types [3]
Simple Types [11]
1. Simple Type Restriction [7]
Conclusions [1]

Simple Types R. Larson: XSD – Part I

(14) 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
- XSD 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")

Simple Types R. Larson: XSD – Part I

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

named-anonymous-simple.xsd (line 3-9)

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

named-anonymous-simple.xsd (line 17-23)

Simple Types R. Larson: XSD – Part I

(16) 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)
XSD 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 [Simple Type Restriction (1)]

Simple Types R. Larson: XSD – Part I

(17) Type Hierarchy

Simple Type Restriction

Outline (Simple Type Restriction)

XSD Types [3]
Simple Types [11]
1. Simple Type Restriction [7]
Conclusions [1]

Simple Type Restriction R. Larson: XSD – Part I

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

built-in.xsd

Simple Type Restriction R. Larson: XSD – Part I

(20) 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
- XSD designers should try to restrict types as much as possible

Simple Type Restriction R. Larson: XSD – Part I

(21) Facets

Facets define a certain way of restricting a simple type
- facets are independent, but they may interact (minLength and maxLength)
- XSD 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

Simple Type Restriction R. Larson: XSD – Part I

(22) Facet Applicability

`string`	length, minLength, maxLength, pattern, enumeration, whiteSpace
`boolean`	pattern, whiteSpace
`float`	pattern, enumeration, whiteSpace, maxInclusive, maxExclusive, minInclusive, minExclusive
`double`	pattern, enumeration, whiteSpace, maxInclusive, maxExclusive, minInclusive, minExclusive
`decimal`	totalDigits, fractionDigits, pattern, whiteSpace, enumeration, maxInclusive, maxExclusive, minInclusive, minExclusive
`duration`	pattern, enumeration, whiteSpace, maxInclusive, maxExclusive, minInclusive, minExclusive
`dateTime`	pattern, enumeration, whiteSpace, maxInclusive, maxExclusive, minInclusive, minExclusive
`time`	pattern, enumeration, whiteSpace, maxInclusive, maxExclusive, minInclusive, minExclusive
`date`	pattern, enumeration, whiteSpace, maxInclusive, maxExclusive, minInclusive, minExclusive
`gYearMonth`	pattern, enumeration, whiteSpace, maxInclusive, maxExclusive, minInclusive, minExclusive
`gYear`	pattern, enumeration, whiteSpace, maxInclusive, maxExclusive, minInclusive, minExclusive
`gMonthDay`	pattern, enumeration, whiteSpace, maxInclusive, maxExclusive, minInclusive, minExclusive
`gDay`	pattern, enumeration, whiteSpace, maxInclusive, maxExclusive, minInclusive, minExclusive
`gMonth`	pattern, enumeration, whiteSpace, maxInclusive, maxExclusive, minInclusive, minExclusive
`hexBinary`	length, minLength, maxLength, pattern, enumeration, whiteSpace
`base64Binary`	length, minLength, maxLength, pattern, enumeration, whiteSpace
`anyURI`	length, minLength, maxLength, pattern, enumeration, whiteSpace
`QName`	length, minLength, maxLength, pattern, enumeration, whiteSpace
`NOTATION`	length, minLength, maxLength, pattern, enumeration, whiteSpace

Simple Type Restriction R. Larson: XSD – Part I

(23) 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 [http://www.w3.org/TR/xmlschema-2/#regexs]
- 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 Restriction R. Larson: XSD – Part I

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

simple-examples.xsd

Simple Type Restriction R. Larson: XSD – Part I

(25) 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 [http://dret.net/lectures/xml-fall08/schemalanguages]) may be used to express these constraints

Conclusions

Outline (Conclusions)

XSD Types [3]
Simple Types [11]
1. Simple Type Restriction [7]
Conclusions [1]

Conclusions R. Larson: XSD – Part I

(27) Typed XML Content

XSD introduces a type layer to schema languages
Types facilitate abstractions (and thus modeling)
Simple types can be restricted to yield more specific types

2011-09-06 XML Foundations [./]
Fall 2011 — INFO 242 (CCN 42596)