# Presentation: 464125

## A Brief Introduction to XML Schema

**A Brief Introduction to XML Schema**

***March 14, 2001***

**Notes:**
Contact XMLSolutions...
877.XML.XMLS
www.xmls.com

## Agenda

- What is XML Schema?
*Current Status*
- Transitioning from DTDs to W3C XML Schema
*Terminology*
*Benefits of W3C XML Schema*
- XML Schema Components
- Clarifying XML Namespaces
- Tools
*Alexander Falk – Altova, Inc.*

## What is XML Schema?

## Information Modeling in XML Syntax

- XDR, SOX, XML Schema
- Object oriented features
- Definition of types
- Inheritance
- Types map to objects
- Types are reusable
- Easier to translate data from programming objects to XML (and back again)

## XML Schema 

- Information modeling language for XML developed by W3C
- Incorporates ideas from SOX and XDR
- Full support for datatypes
- Built in types (integer, boolean, etc.)
- Custom types (telephone numbers, etc.)

**Notes:**
Both SOX and XML Data were submitted to the W3C as proposals for a W3C information modeling syntax.  The best ideas from these proposals have made their way into XML Schema.

## Schema vs. Schemas vs. schema

- Schema
*Refers to the W3C XML Schema*
- Schemas
*Refers to one or more XML vocabularies*
*e.g. xCBL, CXML, BizTalk, IFX, etc. etc.*
- schema (Lowercase)
*Refers to an information model*
*Can be a DTD or Schema*
*May also be a relational database schema*

## Comparing Element Declarations 

- Differences in data typing and syntax

| DTD | <!ELEMENT Age (#PCDATA)> |
| --- | --- |
| XML Schema | <element name=“Age” type=“integer”/> |

| XML | <Age>20009</Age> |
| --- | --- |

**Notes:**
The data contents of an element can only be of string-type in a DTD.  Element declatations in XML Schema enable a wide variety of data-types to be assigned.  Notice that the syntax in the XML Schema example is just XML syntax.

## Current Status

- Recommendation in 3 Parts (latest is Oct. 24, 2000)
- Primer
- Structures
- Data Types
- Status
- CR period has ended
- Voted to go to PR in the next few weeks

## XML Schema Overview

- Comparing XML Schema with DTDs
- XML Schema Features

## Document Type Definition

- An Information Modeling Syntax

- “a is the parent of b.
-  x and y are children of b.”

**<a>**
**     ****<b>**
**	****<x>...</x>**
**	****<y>...</y>**
**    ****</b>**
**</a>**

- Enforces
- Structure

- x and y are always interpreted as
- String, regardless of how they are used

## XML Schema

- Information Modeling Syntax in XML

- a

- b

- x

- y

**<a>**
**     ****<b>**
**	****<x>...</x>**
**	****<y>...</y>**
**    ****</b>**
**</a>**

- Enforces
- Structure

**<xsl:element name=“x” type=“boolean” />**
**<xsl:attribute name=“z” type=“integer” />**

**x and y now have **
**enforceable data types**

## Schema Validation

- Schemas can be used to validate a document in two ways:

**Content Model Validation**
- Checks order and nesting of elements (similar to DTD validation)

**DataType Validation**
- Checks the element content for valid type and range
- example:  month element is an integer between 1 and 12
- <month>5</month>              **VALID!!**
- <month>15</month>            **INVALID!!**

**Notes:**
Attribute values can also be validated.

## Comparison with DTDs

- DTDs use their own unique syntax (SGML)
- XML Schema uses XML syntax
- DTDs are concise
- XML Schema is verbose

## Sample DTD Fragment

**<!ELEMENT LoanML  (Routing , Body )>**
**<!ATTLIST LoanML  xmlns:loanml CDATA  #FIXED 'http://www.loanml.org'**
**                  ****Version      CDATA  #FIXED '1' >**
**<!ELEMENT Routing  (From , To , Processing? )>**
**<!ATTLIST Routing  Transport   CDATA  #REQUIRED**
**                   ****Transaction CDATA  #REQUIRED >**
**<!ELEMENT From  (IDs , RemoteRefNumber , HostNameBack , ServiceNameBack )>**
**<!ATTLIST From  Time    CDATA  #REQUIRED**
**                ****Address CDATA  #REQUIRED**
**                ****Date    CDATA  #REQUIRED >**
**<!ELEMENT IDs  (ID+ )>**
**<!ELEMENT ID  (#PCDATA )>**
**<!ATTLIST ID  Type CDATA  #REQUIRED >**
**<!ELEMENT RemoteRefNumber  (#PCDATA )>**
**<!ELEMENT HostNameBack  (#PCDATA )>**
**<!ELEMENT ServiceNameBack  (#PCDATA )>**
**<!ELEMENT To  (IDs , LocalRefNumber , Destination* , Requests )>**
**<!ELEMENT Destination  (#PCDATA )>bba**

## Sample XML Schema Fragment

**<xsd:element name="a">**
**  ****<xsd:complexType>**
**   ****<xsd:sequence>**
**     ****<xsd:group ref="xyGroup"/>**
**     ****<xsd:group>**
**        ****<xsd:choice>**
**           ****<xsd:element ref="w" />**
**           ****<xsd:element ref="z" />**
**        ****</xsd:choice>**
**     ****</xsd:group>**
**   ****</xsd:sequence>**
**   ****<xsd:attributeGroup ref="rsAttrGroup"/>**
**  ****</xs:complexType>**
**</xsd:element>**** **

## Comparison with DTDs

- XML Schema can be parsed and manipulated programmatically like any other XML document
- DTDs cannot
*(at least not without a bit of work)*
-     ***Note: ****Custom DTD parsers are available, but the ability to parse a DTD is not inherent in most XML Parsers.*
- XML Schema enforce Data Typing
- DTDs cannot
*(DTDs see everything as Strings)*

## Comparison with DTDs

- XML Schema allows **open-ended** data models
*Vocabulary extension and inheritance*
- DTDs support only a closed model
- XML Schema supports attribute groups
*DTDs offer only limited attribute group support*

## Comparison with DTDs

- XML Schema supports namespace integration
*Allows the association of individual nodes of a document with type declarations in a schema*
- DTDs allow only one association (between the document and the DTD)

## Multiple levels of checking

- BookCatalogue.xml

- BookCatalogue1.xsd

- xml-schema.dtd

- Does the xml document
- conform to the rules laid
- out in the xml-schema?

- Is the xml-schema a valid
- xml document, i.e., does it
- conform to the rules laid
- out in the xml-schema DTD?

*© 2000 Roger Costello*

## Schema Features

- Rich Datatypes ( integers, time, date, boolean.. )
- User-defined types
- Extendable types
- Open, closed or refinable content models
- 	*open: Additional elements may appear*
*	**refinable: Additional elements may appear if they are defined in the schema*
- Grouping
- Namespace support

**Notes:**
XML Schema offer a range of new features.
Richer datatypes. Part 2 of the Schema draft defines booleans, numbers, dates and times, URIs, integers, decimal numbers, real numbers, intervals of time, etc.
In addition to these simple, predefined types, there will be facilities for creating other types and aggregate types (although the mechanisms have not been finalized as of the 06 May 1999 draft). 
User defined types, called Archetypes in the draft. An archetype allows you to define your own named datatype. For example, you might define a "PostalAddress" datatype and then define two elements, "ShippingAddress" and "BillingAddress" to be of that type.
This is a more powerful than simply defining the two elements to have the same structure because the shared archetype information is available to the processor. 
Attribute grouping. It's not uncommon to have several attributes that "go together". For example, common attributes that apply to all elements or several attributes that augment graphic or table elements. Attribute grouping allows the schema author to make this relationship explicit. In DTDs, the grouping can be achieved with a parameter entity, simplifying the process of authoring a DTD, but the information is not passed on to the processor. 
Refinable archetypes, or "inheritance". This is probably the most significant new feature in XML Schema. 
A content model defined by a DTD can be described as "closed": it describes all and only what may appear in the content of the element. XML Schema admit two other possibilities: "open" and "refinable". In an open content model, all required elements must be present, but it is not an error for additional elements to also be present. A refinable content model is the middle ground: additional elements may be present, but only if the schema defines what they are. (Consider a schema that extends another: it might refine the content model of some element type to add new elements.) 
Namespace support. Since the introduction of Namespaces in XML, validation has become much more difficult. In fact, until the XML Schema work is completed, it just isn't practical to validate documents that use namespaces.
The XML Schema WD describes mechanisms for schema composition (allowing schemas for multiple namespaces to be combined in a rational way so that validation can be performed) and support for namespaces

## Schemas v. DTDs

- Schemas

- DTDs

- Support namespaces

- n/a

- Written in XML syntax

- n/a

- Full, object-oriented extensibility

- Very limited

- Extensive datatype support

- Extended via
- string substitutions

- Open, closed or refinable
- content models

- Closed only

## In a typical program, up to 60% of the code 

**Code to **
**check **
**the**
** ****structure **
**and content**
**of the data**

**Code to actually**
**do the work**

- In a typical program, up to **60% **of the code
- is spent checking the data!

**Save $$$ using XML Schema**

## Save $$$ using XML Schema (cont.)

- If your data is structured as
- XML and there is a schema,
- then you can hand the
- data-checking task off to a
- schema validator.
- Thus, your code is reduced
- by up to 60%!!!
- Big $$ savings!

**Save $$$ using XML Schema (cont.)**

## NO!

- DTDs have:
- Widespread use and support
- Many legacy applications, documents
- Too much time & money invested
- Experienced programmers/consultants
- There is a _[DTD](file:///D:/DTD%20for%20XMLSchema/index.html)__ to define XML Schema_

**NO!**

## XML Schema Overview

- XML Schema Components

## Primary Schema Components

- XML Namespaces
- Element Declarations
- Attribute Declarations
- Simple Type Definitions
- Complex Type Definitions

**Notes:**
Element and Attribute declarations are needed for information items found in XML instance documents to be validated.
Attributes and elements containing only text will be a simple type.  SimpleType in XML Schema is similar to (#PCDATA) in a DTD, but more powerful.
Elements with child elements and/or attributes will be a complex type.  ComplexType in XML Schema is similar to mixed content (or element only content) in a DTD.

## Primary Schema Components

- <xsd:element name=“size“ type=“xsd:integer” default=“10” >

**Element:**

- <xsd:element ref=“size” default=“12”>

- <xsd:attribute name=“size” type=“xsd:integer” default=“12”>

**Attribute:**

- <xsd:attribute ref=“size” default=“12” use=“optional”>

## Types

- Can be either:
- global and named, or
- local and anonymous
- Simple vs. Complex
- Simple types: PCDATA content, no attributes
- Complex types: child elements and/or attributes

## Secondary Schema Components

- Model Group Definitions
- Attribute Group Definitions
- Identity-constraint Definitions
*Similar to ID / IDREF*
- Notations Declarations
- Wildcards
*Similar to a DTD with “ANY”*
- Annotations

**Notes:**
We will focus on the Primary Schema Components.

Model Groups are similar to the parenthesis in a DTD - groups can be nested.
Attribute 'sets' can be defined in a global Attribute Group, then referenced from various places in the schema.  
ID constraint definitions are similar to ID/IDREF in a DTD, but much more powerful.  They define uniqueness constraints on content.
Notation declaration is the DTD equivalent of NOTATION.
WildCards can be used inside XML schema content models. This is how 'open' content is accomplished.
XML Schema spec uses annotations for documenting schema components.

## XML Schema Overview

- Understanding XML Namespaces

## Used to distinguish between duplicate element type and attribute names
An XML namespace is a collection of element type and attribute names. 
The namespace is identified by a URI.
Two-part naming convention: 
The local name. 
The URI of the XML namespace 

This two part naming convention is the only function of XML Namespaces

- An XML namespace is a collection of element type and attribute names.
*The namespace is identified by a URI.*
*Two-part naming convention: *
*The local name. *
*The URI of the XML namespace *
*This two part naming convention is the ****only**** **function of XML Namespaces*

**XML Namespaces**

*xmlns:foo="http://www.foo.org/" *

## Declaring a Namespace

- XML namespaces are declared with an xmlns attribute
*can associate**	**a prefix with the namespace*
- The declaration is in scope for the element containing the attribute and all its descendants.

** ****<!-- Declares two XML namespaces. Their scope is the A and B elements. -->**
**  ****<A xmlns:foo="http://www.foo.org/" xmlns="http://www.bar.org/">**
**     ****<B>abcd</B>**
**  ****</A>**

## Namespace Prefix

- If an XML namespace declaration contains a prefix, refer the element type or attribute in that namespace with the associated prefix.

-  <!-- A and B are in the http://www.foo.org/ namespace,  which is associated with the foo prefix. -->
-   <foo:A xmlns:foo="http://www.foo.org/">
-      <foo:B>abcd</foo:B>
-   </foo:A>

## No Prefix

- The namespace is the default XML namespace
*Refer to element type names in that namespace ****without****** ****a prefix.*

-  <!-- This is equivalent to the previous example but uses a default namespace instead of the foo prefix. -->
-   <A xmlns="http://www.foo.org/">
-      <B>abcd<B>
-   </A>

## Building from Multiple Vocabularies

- _Book Inventory Vocabulary_
- bookinventory
- book
- title

- _Purchase Order Vocabulary_
- po
- name
- shipTo

- <po>
-   <name>
-   <shipTo>
-   <book>
-      <title>.. </title>

- XML document with
- mixed vocabularies:

## XML Schema Overview

- Tool Support

## Tool support for XML Schema

- All support CR version October 24, 2000
*Some have limitations*
- Parsers
- Xerces
- Oracle XML Parser
- Schema Editors / Validators
- XML Spy
- XML Authority
- XSV

## End of Presentation

- Alexander Falk – Altova, Inc.