You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
3952 lines
282 KiB
3952 lines
282 KiB
<?xml version="1.0" encoding="us-ascii"?>
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
|
<html lang="EN" xmlns="http://www.w3.org/1999/xhtml"><head><meta content="text/html; charset=utf-8" http-equiv="Content-Type"/><title>XML Schema Part 0: Primer Second Edition</title><style type="text/css">
|
|
code { font-family: monospace; }
|
|
|
|
div.constraint,
|
|
div.issue,
|
|
div.note,
|
|
div.notice { margin-left: 2em; }
|
|
|
|
ol.enumar { list-style-type: decimal; }
|
|
ol.enumla { list-style-type: lower-alpha; }
|
|
ol.enumlr { list-style-type: lower-roman; }
|
|
ol.enumua { list-style-type: upper-alpha; }
|
|
ol.enumur { list-style-type: upper-roman; }
|
|
|
|
|
|
div.exampleInner pre { margin-left: 1em;
|
|
margin-top: 0em; margin-bottom: 0em}
|
|
div.exampleOuter {border: 4px double gray;
|
|
margin: 0em; padding: 0em}
|
|
div.exampleInner { background-color: #d5dee3;
|
|
border-top-width: 4px;
|
|
border-top-style: double;
|
|
border-top-color: #d3d3d3;
|
|
border-bottom-width: 4px;
|
|
border-bottom-style: double;
|
|
border-bottom-color: #d3d3d3;
|
|
padding: 4px; margin: 0em }
|
|
div.exampleWrapper { margin: 4px }
|
|
div.exampleHeader { font-weight: bold;
|
|
margin: 4px}
|
|
|
|
img { color: white; border: none }
|
|
span.nav { float: right}
|
|
span.arrow { font-style: normal; font-weight: bold }
|
|
code { font-family: monospace; font-size: 100%}
|
|
span.propdef { font-weight: bold; font-family: monospace }
|
|
span.termdef {color: #850021}
|
|
a.termref:visited, a.termref:link {font-family: sans-serif;
|
|
font-style: normal;
|
|
color: black;
|
|
text-decoration: none }
|
|
a.eltref:visited, a.eltref:link { font-family: sans-serif;
|
|
color: black;
|
|
text-decoration: none }
|
|
a.propref:visited, a.xpropref:visited, a.propref:link, a.xpropref:link { color: black; text-decoration: none;
|
|
font-family: sans-serif }
|
|
dl.props, dl.psvi {margin-bottom: .5em; margin-top: 0em}
|
|
div.toc1 {margin-left: 5ex}
|
|
div.toc2 {margin-left: 2ex}
|
|
div.tocLine{margin: 0em; text-indent: -6ex}
|
|
h3.withToc {margin-bottom: 0em}
|
|
div.constraintnote { margin-top: 1em }
|
|
div.constraint {
|
|
margin-left: 1em; }
|
|
|
|
div.constraintlist {
|
|
margin-left: 1em; margin-bottom: 0em
|
|
}
|
|
div.clnumber {
|
|
text-indent: -1em;
|
|
margin-top: 0em; margin-bottom: 0em }
|
|
|
|
div.schemaComp { border: 4px double gray;
|
|
margin: 0em 1em; padding: 0em }
|
|
div.compHeader { margin: 4px;
|
|
font-weight: bold }
|
|
span.schemaComp { color: #A52A2A }
|
|
div.compBody {
|
|
border-top-width: 4px;
|
|
border-top-style: double;
|
|
border-top-color: #d3d3d3;
|
|
padding: 4px ; margin: 0em}
|
|
|
|
div.psviDef { border: 4px double gray;
|
|
margin: 1em 1em; padding: 0em }
|
|
div.psviHeader { margin: 4px;
|
|
font-weight: bold }
|
|
span.psviDef { color: #A52A2A }
|
|
div.psviBody { border-top-width: 4px;
|
|
border-top-style: double;
|
|
border-top-color: #d3d3d3;
|
|
padding: 4px ; margin: 0em}
|
|
|
|
div.reprdef { border: 4px double gray;
|
|
margin: 0em 1em; padding: 0em }
|
|
div.reprHeader { margin: 4px;
|
|
font-weight: bold }
|
|
span.reprdef { color: #A52A2A }
|
|
div.reprBody, div.reprcomp, div.reprdep {
|
|
border-top-width: 4px;
|
|
border-top-style: double;
|
|
border-top-color: #d3d3d3;
|
|
padding: 4px ; margin: 0em}
|
|
table.reprcomp { margin-bottom: -.5em}
|
|
p.element-syntax-1 { font-family: monospace;
|
|
margin-top: 0em; margin-bottom: .5em }
|
|
p.element-syntax { font-family: monospace;
|
|
border-top-width: 1px;
|
|
border-top-style: solid;
|
|
border-top-color: #d3d3d3;
|
|
padding: 4px ; margin: 0em}
|
|
|
|
div.exampleInner pre { margin-left: 1em;
|
|
margin-top: 0em; margin-bottom: 0em}
|
|
div.exampleOuter {border: 4px double gray;
|
|
margin: 0em; padding: 0em}
|
|
div.exampleInner { background-color: #d5dee3;
|
|
border-top-width: 4px;
|
|
border-top-style: double;
|
|
border-top-color: #d3d3d3;
|
|
border-bottom-width: 4px;
|
|
border-bottom-style: double;
|
|
border-bottom-color: #d3d3d3;
|
|
padding: 4px; margin: 0em }
|
|
div.exampleWrapper { margin: 4px }
|
|
div.exampleHeader { font-weight: bold;
|
|
margin: 4px}
|
|
span.edtext { color: red }
|
|
|
|
table.restricts { margin-top: 1em; margin-bottom: 1em; margin-left: -2em}
|
|
table.restricts th { margin-left: 0em }
|
|
table.ubc td, table.ubc th { font-size: smaller }
|
|
table.dtdemo th { text-align: center;
|
|
background-color: #d5dee3}
|
|
table.dtdemo pre { margin-left: 0em; margin-bottom: 0em}
|
|
table.dtdemo td {background-color: #bedce6}
|
|
table.scrap {background-color: #f5dcb3}
|
|
|
|
img { color: white; border: none }
|
|
span.nav { float: right}
|
|
span.arrow { font-style: normal; font-weight: bold }
|
|
</style><link href="http://www.w3.org/StyleSheets/TR/W3C-REC.css" type="text/css" rel="stylesheet"/></head><body><div class="head"><p><a href="http://www.w3.org/"><img width="72" height="48" alt="W3C" src="http://www.w3.org/Icons/w3c_home"/></a></p>
|
|
<h1><a id="title" name="title"/>XML Schema Part 0: Primer Second Edition</h1>
|
|
<h2><a id="w3c-doctype" name="w3c-doctype"/>W3C Recommendation 28 October 2004</h2>
|
|
<!--*
|
|
<h2><a id="w3c-doctype" name="w3c-doctype"/>W3C Recommendation 2 May 2001, Second Edition 28 October 2004</h2>
|
|
*-->
|
|
<dl><dt>This version:</dt><dd>
|
|
<a href="http://www.w3.org/TR/2004/REC-xmlschema-0-20041028/">http://www.w3.org/TR/2004/REC-xmlschema-0-20041028/</a>
|
|
</dd><dt>Latest version:</dt><dd>
|
|
<a href="http://www.w3.org/TR/xmlschema-0/">http://www.w3.org/TR/xmlschema-0/</a>
|
|
</dd><dt>Previous version:</dt><dd>
|
|
<a href="http://www.w3.org/TR/2004/PER-xmlschema-0-20040318/">http://www.w3.org/TR/2004/PER-xmlschema-0-20040318/</a>
|
|
</dd><dt>Editors:</dt><dd>David C. Fallside, IBM <a href="mailto:fallside@us.ibm.com"><fallside@us.ibm.com></a></dd><dd>Priscilla Walmsley <a href="mailto:pwalmsley@datypic.com"><pwalmsley@datypic.com></a> - Second Edition</dd></dl>
|
|
<p>Please refer to the <a href="http://www.w3.org/2004/03/xmlschema-errata"
|
|
><strong>errata</strong></a>
|
|
for this document, which may include some normative corrections.</p>
|
|
<p>This document is also available in these non-normative formats: <a href="http://www.w3.org/TR/2004/REC-xmlschema-0-20041028/primer.xml">XML</a> and <a href="http://www.w3.org/TR/2004/REC-xmlschema-0-20041028/primer-with-errata.html">XHTML with visible change markup</a>.
|
|
See also <a
|
|
href="http://www.w3.org/2003/03/Translations/byTechnology?technology=xmlschema"
|
|
><strong>translations</strong></a>.</p>
|
|
<p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2004 <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.org/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a>
|
|
<!--*
|
|
and <a href="http://www.w3.org/Consortium/Legal/copyright-software">software licensing</a>
|
|
*-->
|
|
rules apply.</p></div><hr/><div>
|
|
<h2><a id="d0e157" name="d0e157"/>Abstract</h2><p>XML Schema Part 0: Primer is a non-normative document
|
|
intended to provide an easily readable description of the
|
|
XML Schema facilities, and is oriented towards quickly
|
|
understanding how to create schemas using the XML Schema
|
|
language. <a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html">XML
|
|
Schema Part 1: Structures</a> and <a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html">XML
|
|
Schema Part 2: Datatypes</a> provide the complete normative
|
|
description of the XML Schema language. This primer
|
|
describes the language features through numerous examples
|
|
which are complemented by extensive references to the
|
|
normative texts.</p></div><div>
|
|
<h2><a id="status" name="status"/>Status of this Document</h2><p><em>This section describes the status of this document at the
|
|
time of its publication. Other documents may supersede this document.
|
|
A list of current W3C publications and the latest
|
|
revision of this technical report can be found in the <a href="http://www.w3.org/TR/">W3C technical reports index</a> at
|
|
http://www.w3.org/TR/.</em></p><p>This is a <a href="http://www.w3.org/2004/02/Process-20040205/tr.html#RecsW3C">W3C
|
|
Recommendation</a>, the first part of the Second Edition of XML
|
|
Schema. This document has been reviewed by W3C Members and
|
|
other interested parties and has been endorsed by the Director as a
|
|
W3C Recommendation. It is a stable document and may be used as
|
|
reference material.
|
|
W3C's role in making the Recommendation is to draw attention
|
|
to the specification and to promote its widespread deployment. This
|
|
enhances the functionality and interoperability of the Web.
|
|
</p><p>
|
|
This document has been produced by the <a href="http://www.w3.org/XML/Schema">W3C XML Schema Working Group</a>
|
|
as part of the W3C <a href="http://www.w3.org/XML/Activity">XML
|
|
Activity</a>. The goals of the XML Schema language are discussed in
|
|
the <a href="http://www.w3.org/TR/NOTE-xml-schema-req">XML Schema
|
|
Requirements</a> document. The authors of this document are the
|
|
members of the XML Schema Working Group. Different parts of this
|
|
specification have different editors.
|
|
</p><p>
|
|
This document was produced under the <a href="http://www.w3.org/TR/2002/NOTE-patent-practice-20020124">24
|
|
January 2002 Current Patent Practice (CPP)</a> as amended by the <a href="http://www.w3.org/2004/02/05-pp-transition">W3C Patent Policy
|
|
Transition Procedure</a>. The Working Group maintains a <a href="http://www.w3.org/2002/11/xml-schema-IPR-statements.html">public
|
|
list of patent disclosures</a> relevant to this document;
|
|
that page also includes instructions for disclosing a patent.
|
|
An individual who
|
|
has actual knowledge of a patent which the individual believes
|
|
contains Essential Claim(s) with respect to this specification should
|
|
disclose the information in accordance with <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section
|
|
6 of the W3C Patent Policy</a>.
|
|
</p><p>The English version of this specification is the only normative
|
|
version. Information about translations of this document is available
|
|
at <a href="http://www.w3.org/2001/05/xmlschema-translations">http://www.w3.org/2001/05/xmlschema-translations</a>.</p><p>This second edition is <em>not</em> a new version,
|
|
it merely incorporates the changes dictated by the corrections to
|
|
errors found in the <a href="http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/">first
|
|
edition</a> as agreed by the XML Schema Working Group, as a
|
|
convenience to readers. A separate list of all such corrections is
|
|
available at <a href="http://www.w3.org/2001/05/xmlschema-errata">http://www.w3.org/2001/05/xmlschema-errata</a>.
|
|
</p><p>The errata list for this second edition is available at <a href="http://www.w3.org/2004/03/xmlschema-errata">http://www.w3.org/2004/03/xmlschema-errata</a>.</p><p>
|
|
Please report errors in this document to <a href="mailto:www-xml-schema-comments@w3.org">www-xml-schema-comments@w3.org</a>
|
|
(<a href="http://lists.w3.org/Archives/Public/www-xml-schema-comments/">archive</a>).
|
|
</p></div><div class="toc">
|
|
<h2><a id="contents" name="contents"/>Table of Contents</h2><p class="toc">1 <a href="#Intro">Introduction</a><br/>
|
|
2 <a href="#PO">Basic Concepts: The Purchase Order</a><br/>
|
|
    2.1 <a href="#POSchema">The Purchase Order Schema</a><br/>
|
|
    2.2 <a href="#DefnDeclars">Complex Type Definitions, Element & Attribute Declarations</a><br/>
|
|
    2.3 <a href="#CreatDt">Simple Types</a><br/>
|
|
    2.4 <a href="#InlineTypDefn">Anonymous Type Definitions</a><br/>
|
|
    2.5 <a href="#typeContent">Element Content</a><br/>
|
|
    2.6 <a href="#CommVers">Annotations</a><br/>
|
|
    2.7 <a href="#groups">Building Content Models</a><br/>
|
|
    2.8 <a href="#AttrGroups">Attribute Groups</a><br/>
|
|
    2.9 <a href="#Nils">Nil Values</a><br/>
|
|
3 <a href="#NS">Advanced Concepts I: Namespaces, Schemas & Qualification</a><br/>
|
|
    3.1 <a href="#UnqualLocals">Target Namespaces & Unqualified Locals</a><br/>
|
|
    3.2 <a href="#QualLocals">Qualified Locals</a><br/>
|
|
    3.3 <a href="#GlobalvsLocal">Global vs. Local Declarations</a><br/>
|
|
    3.4 <a href="#UndeclaredTNS">Undeclared Target Namespaces</a><br/>
|
|
4 <a href="#IPO">Advanced Concepts II: The International Purchase Order</a><br/>
|
|
    4.1 <a href="#SchemaInMultDocs">A Schema in Multiple Documents</a><br/>
|
|
    4.2 <a href="#DerivExt">Deriving Types by Extension</a><br/>
|
|
    4.3 <a href="#UseDerivInInstDocs">Using Derived Types in Instance Documents</a><br/>
|
|
    4.4 <a href="#DerivByRestrict">Deriving Complex Types by Restriction</a><br/>
|
|
    4.5 <a href="#Redefine">Redefining Types & Groups</a><br/>
|
|
    4.6 <a href="#SubsGroups">Substitution Groups</a><br/>
|
|
    4.7 <a href="#abstract">Abstract Elements and Types</a><br/>
|
|
    4.8 <a href="#restrictingTypeDerivs">Controlling the Creation & Use of Derived Types</a><br/>
|
|
5 <a href="#quartelyReport">Advanced Concepts III: The Quarterly Report</a><br/>
|
|
    5.1 <a href="#specifyingUniqueness">Specifying Uniqueness</a><br/>
|
|
    5.2 <a href="#specifyingKeysAndtheirRefs">Defining Keys & their References</a><br/>
|
|
    5.3 <a href="#schemaConstraintsVsXML1">XML Schema Constraints vs. XML 1.0 ID Attributes</a><br/>
|
|
    5.4 <a href="#import">Importing Types</a><br/>
|
|
    5.5 <a href="#any">Any Element, Any Attribute</a><br/>
|
|
    5.6 <a href="#schemaLocation">schemaLocation</a><br/>
|
|
    5.7 <a href="#conformance">Conformance</a><br/>
|
|
</p>
|
|
<h3><a id="appendices" name="appendices"/>Appendices</h3><p class="toc">A <a href="#Acks">Acknowledgements</a><br/>
|
|
B <a href="#SimpleTypeFacets">Simple Types & their Facets</a><br/>
|
|
C <a href="#usingEntities">Using Entities</a><br/>
|
|
D <a href="#regexAppendix">Regular Expressions</a><br/>
|
|
E <a href="#index">Index</a><br/>
|
|
    E.1 <a href="#indexEl">XML Schema Elements</a><br/>
|
|
    E.2 <a href="#indexAttr">XML Schema Attributes</a><br/>
|
|
</p></div><hr/><div class="body"><div class="div1">
|
|
<h2><a id="Intro" name="Intro"/>1 Introduction</h2><p>
|
|
This document, XML Schema Part 0: Primer, provides an
|
|
easily approachable description of the XML Schema
|
|
definition language, and should be used alongside the
|
|
formal descriptions of the language contained in Parts <a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html">
|
|
1</a> and <a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html">2</a>
|
|
of the XML Schema specification. The intended audience of
|
|
this document includes application developers whose
|
|
programs read and write schema documents, and schema
|
|
authors who need to know about the features of the
|
|
language, especially features that provide functionality
|
|
above and beyond what is provided by DTDs. The text assumes
|
|
that you have a basic understanding of <a href="http://www.w3.org/TR/2000/REC-xml-20001006">XML 1.0</a> and <a href="http://www.w3.org/TR/1999/REC-xml-names-19990114/">Namespaces in XML</a>.
|
|
Each major section of the primer introduces new features of
|
|
the language, and describes those features in the context
|
|
of concrete examples.
|
|
</p><p>
|
|
<a href="#PO">Basic Concepts: The Purchase Order (§2)</a> covers the basic mechanisms of
|
|
XML Schema. It describes how to declare the elements and
|
|
attributes that appear in XML documents, the distinctions
|
|
between simple and complex types, defining complex types,
|
|
the use of simple types for element and attribute values,
|
|
schema annotation, a simple mechanism for re-using element
|
|
and attribute definitions, and nil values.
|
|
</p><p>
|
|
<a href="#NS">Advanced Concepts I: Namespaces, Schemas & Qualification (§3)</a>, the first advanced section in
|
|
the primer, explains the basics of how namespaces are used
|
|
in XML and schema documents. This section is important for
|
|
understanding many of the topics that appear in the other
|
|
advanced sections.
|
|
</p><p>
|
|
<a href="#IPO">Advanced Concepts II: The International Purchase Order (§4)</a>, the second advanced section
|
|
in the primer, describes mechanisms for deriving types from
|
|
existing types, and for controlling these derivations. The
|
|
section also describes mechanisms for merging together
|
|
fragments of a schema from multiple sources, and for
|
|
element substitution.
|
|
</p><p>
|
|
<a href="#quartelyReport">Advanced Concepts III: The Quarterly Report (§5)</a> covers more
|
|
advanced features, including a mechanism for specifying
|
|
uniqueness among attributes and elements, a mechanism for
|
|
using types across namespaces, a mechanism for extending
|
|
types based on namespaces, and a description of how
|
|
documents are checked for conformance.
|
|
</p><p>
|
|
In addition to the sections just described, the primer
|
|
contains a number of appendices that
|
|
provide detailed reference information on simple types and
|
|
a regular expression language.
|
|
</p><p>
|
|
The primer is a non-normative document, which means that
|
|
it does not provide a definitive (from the W3C's point of
|
|
view) specification of the XML Schema language. The
|
|
examples and other explanatory material in this document
|
|
are provided to help you understand XML Schema, but they
|
|
may not always provide definitive answers. In such cases,
|
|
you will need to refer to the XML Schema specification, and
|
|
to help you do this, we provide many links pointing to the
|
|
relevant parts of the specification. More specifically, XML
|
|
Schema items mentioned in the primer text are linked to an
|
|
index [<a href="#index">Index (§E)</a>] of element names and attributes,
|
|
and a summary <a href="#simpleTypesTable">table</a> of
|
|
datatypes, both in the primer. The table and the index
|
|
contain links to the relevant sections of XML Schema parts
|
|
1 and 2.
|
|
</p></div><div class="div1">
|
|
<h2><a id="PO" name="PO"/>2 Basic Concepts: The Purchase Order</h2><p>
|
|
The purpose of a schema is to define a class of XML
|
|
documents, and so the term "instance document" is often
|
|
used to describe an XML document that conforms to a
|
|
particular schema. In fact, neither instances nor schemas
|
|
need to exist as documents <em>per se</em> -- they may
|
|
exist as streams of bytes sent between applications, as
|
|
fields in a database record, or as collections of XML
|
|
Infoset "Information Items" -- but to simplify the primer,
|
|
we have chosen to always refer to instances and schemas as
|
|
if they are documents and files.
|
|
</p><p>
|
|
Let us start by considering an instance document in a file
|
|
called <code><a href="#po.xml">po.xml</a></code>. It
|
|
describes a purchase order generated by a home products
|
|
ordering and billing application:
|
|
</p><div class="exampleOuter"><a id="po.xml" name="po.xml"/><div class="exampleHeader">Example</div><div class="exampleWrapper">The Purchase Order, po.xml</div><div class="exampleInner"><pre>
|
|
<?xml version="1.0"?>
|
|
<purchaseOrder orderDate="1999-10-20">
|
|
<shipTo country="US">
|
|
<name>Alice Smith</name>
|
|
<street>123 Maple Street</street>
|
|
<city>Mill Valley</city>
|
|
<state>CA</state>
|
|
<zip>90952</zip>
|
|
</shipTo>
|
|
<billTo country="US">
|
|
<name>Robert Smith</name>
|
|
<street>8 Oak Avenue</street>
|
|
<city>Old Town</city>
|
|
<state>PA</state>
|
|
<zip>95819</zip>
|
|
</billTo>
|
|
<comment>Hurry, my lawn is going wild<!/comment>
|
|
<items>
|
|
<item partNum="872-AA">
|
|
<productName>Lawnmower</productName>
|
|
<quantity>1</quantity>
|
|
<USPrice>148.95</USPrice>
|
|
<comment>Confirm this is electric</comment>
|
|
</item>
|
|
<item partNum="926-AA">
|
|
<productName>Baby Monitor</productName>
|
|
<quantity>1</quantity>
|
|
<USPrice>39.98</USPrice>
|
|
<shipDate>1999-05-21</shipDate>
|
|
</item>
|
|
</items>
|
|
</purchaseOrder>
|
|
</pre></div></div><p>
|
|
The purchase order consists of a main element, <code>
|
|
purchaseOrder</code>, and the subelements <code>
|
|
shipTo</code>, <code>billTo</code>, <code>comment</code>,
|
|
and <code>items</code>. These subelements (except <code>
|
|
comment</code>) in turn contain other subelements, and so
|
|
on, until a subelement such as <code>USPrice</code>
|
|
contains a number rather than any subelements. Elements
|
|
that contain subelements or carry attributes are said to
|
|
have complex types, whereas elements that contain numbers
|
|
(and strings, and dates, etc.) but do not contain any
|
|
subelements are said to have simple types. Some elements
|
|
have attributes; attributes always have simple types.
|
|
</p><p>
|
|
The complex types in the instance document, and some of
|
|
the simple types, are defined in the schema for purchase
|
|
orders. The other simple types are defined as part of XML
|
|
Schema's repertoire of built-in simple types.
|
|
</p><p>
|
|
Before going on to examine the purchase order schema, we
|
|
digress briefly to mention the association between the
|
|
instance document and the purchase order schema. As you can
|
|
see by inspecting the instance document, the purchase order
|
|
schema is not mentioned. An instance is not actually
|
|
required to reference a schema, and although many will, we
|
|
have chosen to keep this first section simple, and to
|
|
assume that any processor of the instance document can
|
|
obtain the purchase order schema without any information
|
|
from the instance document. In later sections, we will
|
|
introduce explicit mechanisms for associating instances and
|
|
schemas.
|
|
</p><div class="div2">
|
|
<h3><span class="nav"> <a class="nav" href="#DefnDeclars"><img src="next.jpg" alt="next sub-section"/></a></span><a id="POSchema" name="POSchema"/>2.1 The Purchase Order Schema</h3><p>
|
|
The purchase order schema is contained in the file <code>
|
|
<a href="#po.xsd">po.xsd</a></code>:
|
|
</p><div class="exampleOuter"><a id="po.xsd" name="po.xsd"/><div class="exampleHeader">Example</div><div class="exampleWrapper">The Purchase Order Schema, po.xsd</div><div class="exampleInner"><pre>
|
|
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
|
|
|
|
<xsd:annotation>
|
|
<xsd:documentation xml:lang="en">
|
|
Purchase order schema for Example.com.
|
|
Copyright 2000 Example.com. All rights reserved.
|
|
</xsd:documentation>
|
|
</xsd:annotation>
|
|
|
|
<xsd:element name="purchaseOrder" type="PurchaseOrderType"/>
|
|
|
|
<xsd:element name="comment" type="xsd:string"/>
|
|
|
|
<xsd:complexType name="PurchaseOrderType">
|
|
<xsd:sequence>
|
|
<xsd:element name="shipTo" type="USAddress"/>
|
|
<xsd:element name="billTo" type="USAddress"/>
|
|
<xsd:element ref="comment" minOccurs="0"/>
|
|
<xsd:element name="items" type="Items"/>
|
|
</xsd:sequence>
|
|
<xsd:attribute name="orderDate" type="xsd:date"/>
|
|
</xsd:complexType>
|
|
|
|
<xsd:complexType name="USAddress">
|
|
<xsd:sequence>
|
|
<xsd:element name="name" type="xsd:string"/>
|
|
<xsd:element name="street" type="xsd:string"/>
|
|
<xsd:element name="city" type="xsd:string"/>
|
|
<xsd:element name="state" type="xsd:string"/>
|
|
<xsd:element name="zip" type="xsd:decimal"/>
|
|
</xsd:sequence>
|
|
<xsd:attribute name="country" type="xsd:NMTOKEN"
|
|
fixed="US"/>
|
|
</xsd:complexType>
|
|
|
|
<xsd:complexType name="Items">
|
|
<xsd:sequence>
|
|
<xsd:element name="item" minOccurs="0" maxOccurs="unbounded">
|
|
<xsd:complexType>
|
|
<xsd:sequence>
|
|
<xsd:element name="productName" type="xsd:string"/>
|
|
<xsd:element name="quantity">
|
|
<xsd:simpleType>
|
|
<xsd:restriction base="xsd:positiveInteger">
|
|
<xsd:maxExclusive value="100"/>
|
|
</xsd:restriction>
|
|
</xsd:simpleType>
|
|
</xsd:element>
|
|
<xsd:element name="USPrice" type="xsd:decimal"/>
|
|
<xsd:element ref="comment" minOccurs="0"/>
|
|
<xsd:element name="shipDate" type="xsd:date" minOccurs="0"/>
|
|
</xsd:sequence>
|
|
<xsd:attribute name="partNum" type="SKU" use="required"/>
|
|
</xsd:complexType>
|
|
</xsd:element>
|
|
</xsd:sequence>
|
|
</xsd:complexType>
|
|
|
|
<!-- Stock Keeping Unit, a code for identifying products -->
|
|
<xsd:simpleType name="SKU">
|
|
<xsd:restriction base="xsd:string">
|
|
<xsd:pattern value="\d{3}-[A-Z]{2}"/>
|
|
</xsd:restriction>
|
|
</xsd:simpleType>
|
|
|
|
</xsd:schema>
|
|
</pre></div></div><p>
|
|
The purchase order schema consists of a <code><a href="#element-schema">schema</a></code> element and a variety
|
|
of subelements, most notably <code><a href="#element-element">element</a></code>, <code><a href="#element-complexType">complexType</a></code>, and <code><a href="#element-simpleType">simpleType</a></code> which
|
|
determine the appearance of elements and their content in
|
|
instance documents.
|
|
</p><p id="ref1">Each of the elements in the schema has
|
|
a prefix <code>xsd:</code> which is associated with the XML
|
|
Schema namespace through the declaration, <code>
|
|
xmlns:xsd="http://www.w3.org/2001/XMLSchema"</code>,
|
|
that appears in the <code><a href="#element-schema">
|
|
schema</a></code> element. The prefix <code>xsd:</code> is
|
|
used by convention to denote the XML Schema namespace,
|
|
although any prefix can be used. The same prefix, and hence
|
|
the same association, also appears on the names of built-in
|
|
simple types, e.g. <code>xsd:<a href="#string">string</a></code>. The purpose of the association
|
|
is to identify the elements and simple types as belonging
|
|
to the vocabulary of the XML Schema language rather than
|
|
the vocabulary of the schema author. For the sake of
|
|
clarity in the text, we just mention the names of elements
|
|
and simple types (e.g. <code><a href="#element-simpleType">
|
|
simpleType</a></code>), and omit the prefix.
|
|
</p></div><div class="div2">
|
|
<h3 class="withToc"><span class="nav"><a class="nav" href="#POSchema"><img src="previous.jpg" alt="previous sub-section"/></a> <a class="nav" href="#CreatDt"><img src="next.jpg" alt="next sub-section"/></a></span><a id="DefnDeclars" name="DefnDeclars"/>2.2 Complex Type Definitions, Element & Attribute Declarations</h3><div class="localToc">        2.2.1 <a href="#OccurrenceConstraints">Occurrence Constraints</a><br/>
|
|
        2.2.2 <a href="#Globals">Global Elements & Attributes</a><br/>
|
|
        2.2.3 <a href="#NamingConflicts">Naming Conflicts</a><br/>
|
|
</div><p>
|
|
In XML Schema, there is a basic difference between complex
|
|
types which allow elements in their content and may carry
|
|
attributes, and simple types which cannot have element
|
|
content and cannot carry attributes. There is also a major
|
|
distinction between definitions which create new types
|
|
(both simple and complex), and declarations which enable
|
|
elements and attributes with specific names and types (both
|
|
simple and complex) to appear in document instances. In
|
|
this section, we focus on defining complex types and
|
|
declaring the elements and attributes that appear within
|
|
them.
|
|
</p><p id="ref2">New complex types are defined using
|
|
the <code><a href="#element-complexType">
|
|
complexType</a></code> element and such definitions
|
|
typically contain a set of element declarations, element
|
|
references, and attribute declarations. The declarations
|
|
are not themselves types, but rather an association between
|
|
a name and the constraints which govern the appearance of that
|
|
name in documents governed by the associated schema.
|
|
Elements are declared using the <code><a href="#element-element">element</a></code> element, and
|
|
attributes are declared using the <code><a href="#element-attribute">attribute</a></code> element. For
|
|
example, <code>USAddress</code> is defined as a complex
|
|
type, and within the definition of <code>USAddress</code>
|
|
we see five element declarations and one attribute
|
|
declaration:
|
|
</p><div class="exampleOuter"><a id="DefiningtheUSAddressType" name="DefiningtheUSAddressType"/><div class="exampleHeader">Example</div><div class="exampleWrapper">Defining the USAddress Type</div><div class="exampleInner"><pre>
|
|
<xsd:complexType name="USAddress" >
|
|
<xsd:sequence>
|
|
<xsd:element name="name" type="xsd:string"/>
|
|
<xsd:element name="street" type="xsd:string"/>
|
|
<xsd:element name="city" type="xsd:string"/>
|
|
<xsd:element name="state" type="xsd:string"/>
|
|
<xsd:element name="zip" type="xsd:decimal"/>
|
|
</xsd:sequence>
|
|
<xsd:attribute name="country" type="xsd:NMTOKEN" fixed="US"/>
|
|
</xsd:complexType>
|
|
</pre></div></div><p id="ref3">The consequence of this definition is
|
|
that any element appearing in an instance whose type is
|
|
declared to be <code>USAddress</code> (e.g. <code>
|
|
shipTo</code> in <code> <a href="#po.xml">
|
|
po.xml</a></code>) must consist of five elements and one
|
|
attribute. These elements must be called <code>name</code>,
|
|
<code>street</code>, <code> city</code>, <code>state</code>
|
|
and <code>zip</code> as specified by the values of the
|
|
declarations' <code>name</code> attributes, and the
|
|
elements must appear in the same sequence (order) in which
|
|
they are declared. The first four of these elements will
|
|
each contain a string, and the fifth will contain a
|
|
number. The element whose type is declared to be <code>
|
|
USAddress</code> may appear with an attribute called <code>
|
|
country</code> which must contain the string <code>
|
|
US</code>.
|
|
</p><p id="ref4">The <code>USAddress</code> definition
|
|
contains only declarations involving the simple types: <code><a href="#string">string</a></code>, <code><a href="#decimal">
|
|
decimal</a></code> and <code><a href="#NMTOKEN">
|
|
NMTOKEN</a></code>. In contrast, the <code>
|
|
PurchaseOrderType</code> definition contains element
|
|
declarations involving complex types, e.g. <code>
|
|
USAddress</code>, although note that both declarations use
|
|
the same <code><a href="#attribute-type">type</a></code>
|
|
attribute to identify the type, regardless of whether the
|
|
type is simple or complex.
|
|
</p><div class="exampleOuter"><a id="DefiningPurchaseOrderType" name="DefiningPurchaseOrderType"/><div class="exampleHeader">Example</div><div class="exampleWrapper">Defining PurchaseOrderType</div><div class="exampleInner"><pre>
|
|
<xsd:complexType name="PurchaseOrderType">
|
|
<xsd:sequence>
|
|
<xsd:element name="shipTo" type="USAddress"/>
|
|
<xsd:element name="billTo" type="USAddress"/>
|
|
<xsd:element ref="comment" minOccurs="0"/>
|
|
<xsd:element name="items" type="Items"/>
|
|
</xsd:sequence>
|
|
<xsd:attribute name="orderDate" type="xsd:date"/>
|
|
</xsd:complexType>
|
|
</pre></div></div><p>
|
|
In defining <code>PurchaseOrderType</code>, two of the
|
|
element declarations, for <code>shipTo</code> and <code>
|
|
billTo</code>, associate different element names with the
|
|
same complex type, namely <code>USAddress</code>. The
|
|
consequence of this definition is that any element
|
|
appearing in an instance document (e.g. <code><a href="#po.xml">
|
|
po.xml</a></code>) whose type is declared to be <code>
|
|
PurchaseOrderType</code> must consist of elements named
|
|
<code>shipTo</code> and <code> billTo,</code> each
|
|
containing the five subelements (<code>name</code>, <code>
|
|
street</code>, <code>city</code>, <code>state</code> and
|
|
<code>zip</code>) that were declared as part of <code>
|
|
USAddress</code>. The <code>shipTo</code> and <code>
|
|
billTo</code> elements may also carry the <code>
|
|
country</code> attribute that was declared as part of
|
|
<code>USAddress</code>.
|
|
</p><p>
|
|
The <code>PurchaseOrderType</code> definition contains an
|
|
<code>orderDate</code> attribute declaration which, like
|
|
the <code>country</code> attribute declaration, identifies
|
|
a simple type. In fact, all attribute declarations must
|
|
reference simple types because, unlike element
|
|
declarations, attributes cannot contain other elements or
|
|
other attributes.
|
|
</p><p id="ref5">The element declarations we have
|
|
described so far have each associated a name with an
|
|
existing type definition. Sometimes it is preferable to use
|
|
an existing element rather than declare a new element, for
|
|
example:
|
|
</p><div class="exampleOuter"><div class="exampleHeader">Example</div><div class="exampleInner"><pre>
|
|
<xsd:element ref="comment" minOccurs="0"/>
|
|
</pre></div></div><p>
|
|
This declaration references an existing element, <code>
|
|
comment</code>, that was declared elsewhere in the purchase
|
|
order schema. In general, the value of the <code><a href="#attribute-ref">ref</a></code> attribute must reference a
|
|
global element, i.e. one that has been declared under
|
|
<code><a href="#element-schema">schema</a></code> rather
|
|
than as part of a complex type definition. The consequence
|
|
of this declaration is that an element called <code>
|
|
comment</code> may appear in an instance document, and its
|
|
content must be consistent with that element's type, in
|
|
this case, <code><a href="#string">string</a></code>.
|
|
</p><div class="div3">
|
|
<h4><a id="OccurrenceConstraints" name="OccurrenceConstraints"/>2.2.1 Occurrence Constraints</h4><p id="ref6">The <code>comment</code> element is
|
|
optional within <code> PurchaseOrderType</code> because the
|
|
value of the <code><a href="#attribute-minOccurs">
|
|
minOccurs</a></code> attribute in its declaration is 0. In
|
|
general, an element is required to appear when the value of
|
|
<code><a href="#attribute-minOccurs">minOccurs</a></code>
|
|
is 1 or more. The maximum number of times an element may
|
|
appear is determined by the value of a <code><a href="#attribute-maxOccurs">maxOccurs</a></code> attribute in
|
|
its declaration. This value may be a positive integer such
|
|
as 41, or the term <code>unbounded</code> to indicate there
|
|
is no maximum number of occurrences. The default value for
|
|
both the <code><a href="#attribute-minOccurs">
|
|
minOccurs</a></code> and the <code><a href="#attribute-maxOccurs">maxOccurs</a></code> attributes is
|
|
1. Thus, when an element such as <code>comment</code> is
|
|
declared without a <code> <a href="#attribute-maxOccurs">
|
|
maxOccurs</a></code> attribute, the element may not occur
|
|
more than once. Be sure that if you specify a value for
|
|
only the <code><a href="#attribute-minOccurs">
|
|
minOccurs</a></code> attribute, it is less than or equal to
|
|
the default value of <code><a href="#attribute-maxOccurs">
|
|
maxOccurs</a></code>, i.e. it is 0 or 1. Similarly, if you
|
|
specify a value for only the <code><a href="#attribute-maxOccurs">maxOccurs</a></code> attribute, it
|
|
must be greater than or equal to the default value of
|
|
<code><a href="#attribute-minOccurs">minOccurs</a></code>,
|
|
i.e. 1 or more. If both attributes are omitted, the element
|
|
must appear exactly once.
|
|
</p><p id="ref36">Attributes may appear once or not at
|
|
all, but no other number of times, and so the
|
|
syntax for specifying
|
|
occurrences of attributes is different than the syntax for
|
|
elements. In particular, attributes can be declared with a
|
|
<code><a href="#attribute-use">use</a></code> attribute
|
|
to indicate whether the attribute is <code>
|
|
required</code> (see for example, the <code>partNum</code>
|
|
attribute declaration in <code><a href="#po.xsd">
|
|
po.xsd</a></code>), <code>optional</code>, or even
|
|
<code>prohibited</code>.
|
|
</p><p>
|
|
Default values of both attributes and elements are declared using the
|
|
<code>default</code> attribute, although this attribute has a slightly
|
|
different consequence in each case. When an attribute is declared with a
|
|
default value, the value of the attribute is whatever value
|
|
appears as the attribute's value in an instance document; if
|
|
the attribute does not appear in the instance document, the schema
|
|
processor provides the attribute with a value equal to that of the
|
|
<code><a href="#attribute-attr-default"> default</a></code> attribute.
|
|
Note that default values for attributes only make sense if the
|
|
attributes themselves are optional, and so it is an error to specify
|
|
both a default value and anything other than a value of
|
|
<code>optional</code> for <code> <a href="#attribute-use">use</a></code>.
|
|
</p><p>
|
|
The schema processor treats defaulted elements slightly differently.
|
|
When an element is declared with a default value, the value of the
|
|
element is whatever value appears as the element's content in the
|
|
instance document; if the element appears without any content, the
|
|
schema processor provides the element with a value equal to that of the
|
|
<code><a href="#attribute-attr-default">default</a></code> attribute.
|
|
However, if the element does not appear in the instance document, the schema
|
|
processor does not provide the element at all. In summary, the
|
|
differences between element and attribute defaults can be stated as:
|
|
Default attribute values apply when attributes are missing, and default
|
|
element values apply when elements are empty.
|
|
</p><p id="ref55">
|
|
The <code>fixed</code> attribute is used in both attribute and element
|
|
declarations to ensure that the attributes and elements are
|
|
set to particular values. For example, <code><a href="#po.xsd">po.xsd
|
|
</a></code> contains a declaration for the <code>country</code>
|
|
attribute, which is declared with a <code><a href="#attribute-attr-fixed">fixed</a></code> value <code>US</code>. This
|
|
declaration means that the appearance of a <code>country</code>
|
|
attribute in an instance document is optional (the default value of <code>
|
|
<a href="#attribute-use">use</a></code> is <code>optional</code>),
|
|
although if the attribute does appear, its value must be <code>US</code>,
|
|
and if the attribute does not appear, the schema processor will provide
|
|
a <code>country</code> attribute with the value <code>US</code>. Note
|
|
that the concepts of a fixed value and a default value are mutually
|
|
exclusive, and so it is an error for a declaration to contain both
|
|
<code>fixed</code> and <code>default</code> attributes.
|
|
</p><p>
|
|
The values of the attributes used in element and attribute
|
|
declarations to constrain their occurrences are summarized in
|
|
<a href="#cardinalityTable">Table 1</a>.
|
|
</p><a id="cardinalityTable" name="cardinalityTable"/><table summary="occurrence constraints" width="100%" border="2"><tbody><tr><th colspan="3" align="left">Table 1. Occurrence Constraints for Elements and Attributes</th></tr><tr><th>
|
|
<table border="0"><tbody><tr><th>Elements</th></tr><tr><th>(<a href="#attribute-minOccurs">minOccurs</a>, <a href="#attribute-maxOccurs">maxOccurs</a>)</th></tr><tr><th><a href="#attribute-fixed">fixed</a>, <a href="#attribute-default">default</a></th></tr></tbody></table>
|
|
</th><th>
|
|
<table border="0"><tbody><tr><th>Attributes</th></tr><tr><th><a href="#attribute-use">use</a>, <a href="#attribute-attr-fixed">fixed</a>, <a href="#attribute-attr-default">default</a></th></tr></tbody></table>
|
|
</th><th>Notes</th></tr><tr><td align="center">(1, 1) -, -</td><td align="center">required, -, -</td><td>element/attribute must appear once, it may have any value</td></tr><tr><td align="center">(1, 1) 37, -</td><td align="center">required, 37, -</td><td>element/attribute must appear once, its value must be 37</td></tr><tr><td align="center">(2, unbounded) 37, -</td><td align="center">n/a</td><td>element must appear twice or more, its value must be
|
|
37; in general, <a href="#attribute-minOccurs">
|
|
minOccurs</a> and <a href="#attribute-maxOccurs">
|
|
maxOccurs</a> values may be positive integers, and
|
|
<a href="#attribute-maxOccurs">maxOccurs</a> value
|
|
may also be "unbounded"</td></tr><tr><td align="center">(0, 1) -, -</td><td align="center">optional, -, -</td><td>element/attribute may appear once, it may have any value</td></tr><tr><td align="center">(0, 1) 37, -</td><td align="center">n/a</td><td>element may appear once, if it does not
|
|
appear it is not provided; if it does appear and it is empty, its
|
|
value is 37; if it does appear and it is not empty,
|
|
its value must be 37</td></tr><tr><td align="center">n/a</td><td align="center">optional, 37, -</td><td>attribute may appear once, if it does appear
|
|
its value must be 37, if it does not appear its value is 37</td></tr><tr><td align="center">(0, 1) -, 37</td><td align="center">n/a</td><td>element may appear once; if it does not
|
|
appear it is not provided; if it does
|
|
appear and it is empty, its value is 37; otherwise its value is that
|
|
given</td></tr><tr><td align="center">n/a</td><td align="center">optional, -, 37</td><td>attribute may appear once; if it does not
|
|
appear its value is 37, otherwise its value is that given</td></tr><tr><td align="center">(0, 2) -, 37</td><td align="center">n/a</td><td>element may appear once, twice, or not at all; if the
|
|
element does not appear it is not provided; if it does
|
|
appear and it is empty, its value is 37; otherwise its
|
|
value is that given; in general, <a href="#attribute-minOccurs">minOccurs</a> and <a href="#attribute-maxOccurs">maxOccurs</a> values may be
|
|
positive integers, and <a href="#attribute-maxOccurs">maxOccurs</a> value may also
|
|
be "unbounded"</td></tr><tr><td align="center">(0, 0) -, -</td><td align="center">prohibited, -, -</td><td>element/attribute must not appear</td></tr><tr><td colspan="3">
|
|
Note that neither <a href="#attribute-minOccurs">
|
|
minOccurs</a>, <a href="#attribute-maxOccurs">
|
|
maxOccurs</a>, nor <a href="#attribute-use">use</a>
|
|
may appear in the declarations of global elements and
|
|
attributes.</td></tr></tbody></table></div><div class="div3">
|
|
<h4><a id="Globals" name="Globals"/>2.2.2 Global Elements & Attributes</h4><p>
|
|
Global elements, and global attributes, are created by
|
|
declarations that appear as the children of the <code><a href="#element-schema">schema</a></code> element. Once
|
|
declared, a global element or a global attribute can be
|
|
referenced in one or more declarations using the <code><a href="#attribute-ref">ref</a></code> attribute as described
|
|
above. A declaration that references a global element
|
|
enables the referenced element to appear in the instance
|
|
document in the context of the referencing declaration. So, for
|
|
example, the <code>comment</code> element appears in <code>
|
|
<a href="#po.xml">po.xml</a></code> at the same level as
|
|
the <code>shipTo</code>, <code>billTo</code> and <code>
|
|
items</code> elements because the declaration that
|
|
references <code>comment</code> appears in the complex type
|
|
definition at the same level as the declarations of the
|
|
other three elements.
|
|
</p><p>
|
|
The declaration of a global element also enables the
|
|
element to appear at the top-level of an instance document.
|
|
Hence <code>purchaseOrder</code>, which is declared as a
|
|
global element in <code><a href="#po.xsd">
|
|
po.xsd</a></code>, can appear as the top-level element in
|
|
<code><a href="#po.xml">po.xml</a></code>. Note that this
|
|
rationale will also allow a <code>comment</code> element to
|
|
appear as the top-level element in a document like
|
|
<code><a href="#po.xml"> po.xml</a></code>.
|
|
</p><p>
|
|
There are a number of caveats concerning the use of
|
|
global elements and attributes. One caveat is that global
|
|
declarations cannot contain references; global declarations
|
|
must identify simple and complex types directly. Put
|
|
concretely, global declarations cannot contain the <code><a href="#attribute-ref">ref</a></code> attribute, they must
|
|
use the <code><a href="#attribute-type">type</a></code>
|
|
attribute (or, as we describe shortly, be followed by an <a href="#InlineTypDefn">anonymous type definition</a>). A
|
|
second caveat is that cardinality constraints cannot be
|
|
placed on global declarations, although they can be placed
|
|
on local declarations that reference global declarations.
|
|
In other words, global declarations cannot contain the
|
|
attributes <a href="#attribute-minOccurs">minOccurs</a>, <a href="#attribute-maxOccurs"> maxOccurs</a>, or <a href="#attribute-use">use</a>.
|
|
</p></div><div class="div3">
|
|
<h4><a id="NamingConflicts" name="NamingConflicts"/>2.2.3 Naming Conflicts</h4><p>
|
|
We have now described how to define new complex types
|
|
(e.g. <code>PurchaseOrderType</code>), declare elements
|
|
(e.g. <code>purchaseOrder</code>) and declare attributes
|
|
(e.g. <code>orderDate</code>). These activities generally
|
|
involve naming, and so the question naturally arises: What
|
|
happens if we give two things the same name? The answer
|
|
depends upon the two things in question, although in
|
|
general the more similar are the two things, the more
|
|
likely there will be a conflict.
|
|
</p><p>
|
|
Here are some examples to illustrate when same names cause
|
|
problems. If the two things are both types, say we define a
|
|
complex type called USStates and a simple type called
|
|
USStates, there is a conflict. If the two things are a type
|
|
and an element or attribute, say we define a complex type
|
|
called USAddress and we declare an element called USAddress,
|
|
there is no conflict. If the two things are elements within
|
|
different types (i.e. not global elements), say we declare
|
|
one element called name as part of the USAddress type and a
|
|
second element called name as part of the Item type, there
|
|
is no conflict. (Such elements are sometimes called local
|
|
element declarations.) Finally, if the two things are both
|
|
types and you define one and XML Schema has defined the
|
|
other, say you define a simple type called decimal, there
|
|
is no conflict. The reason for the apparent contradiction
|
|
in the last example is that the two types belong to
|
|
different namespaces. We explore the use of namespaces
|
|
in schema in a later section.
|
|
</p></div></div><div class="div2">
|
|
<h3 class="withToc"><span class="nav"><a class="nav" href="#DefnDeclars"><img src="previous.jpg" alt="previous sub-section"/></a> <a class="nav" href="#InlineTypDefn"><img src="next.jpg" alt="next sub-section"/></a></span><a id="CreatDt" name="CreatDt"/>2.3 Simple Types</h3><div class="localToc">        2.3.1 <a href="#ListDt">List Types</a><br/>
|
|
        2.3.2 <a href="#UnionDt">Union Types</a><br/>
|
|
</div><p>
|
|
The purchase order schema declares several elements and
|
|
attributes that have simple types. Some of these simple
|
|
types, such as <code><a href="#string">string</a></code>
|
|
and <code><a href="#decimal">decimal</a></code>, are built
|
|
in to XML Schema, while others are derived from the
|
|
built-in's. For example, the <code>partNum</code> attribute
|
|
has a type called <code>SKU</code> (Stock Keeping Unit)
|
|
that is derived from <code><a href="#string">
|
|
string</a></code>. Both built-in simple types and their
|
|
derivations can be used in all element and attribute
|
|
declarations. <a href="#simpleTypesTable">Table 2</a> lists
|
|
all the simple types built in to XML Schema, along with
|
|
examples of the different types.
|
|
</p><a id="simpleTypesTable" name="simpleTypesTable"/><table summary="built-in simple types" width="100%" border="2"><tbody><tr><th colspan="3" align="left">Table 2. Simple Types Built In to XML Schema</th></tr><tr><th align="left">Simple Type</th><th align="left">Examples (delimited by commas)</th><th align="left">Notes</th></tr><tr><td id="string"><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#string">string</a></td><td>Confirm this is electric</td><td> </td></tr><tr><td id="normalizedString">
|
|
<a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#normalizedString">normalizedString</a></td><td>Confirm this is electric</td><td>see (3)</td></tr><tr><td id="token"><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#token">token</a></td><td>Confirm this is electric</td><td>see (4)</td></tr><tr><td id="base64Binary"><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#base64Binary">
|
|
base64Binary</a></td><td>GpM7</td><td> </td></tr><tr><td id="hexBinary"><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#hexBinary">hexBinary</a></td><td>0FB7</td><td> </td></tr><tr><td id="integer"><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#integer">integer</a></td><td>...-1, 0, 1, ...</td><td>see (2)</td></tr><tr><td id="positiveInteger"><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#positiveInteger">positiveInteger</a></td><td>1, 2, ...</td><td>see (2)</td></tr><tr><td id="negativeInteger"><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#negativeInteger">
|
|
negativeInteger</a></td><td>... -2, -1</td><td>see (2)</td></tr><tr><td id="nonNegativeInteger"><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#nonNegativeInteger">nonNegativeInteger</a></td><td>0, 1, 2, ...</td><td>see (2)</td></tr><tr><td id="nonPositiveInteger"><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#nonPositiveInteger">nonPositiveInteger</a></td><td>... -2, -1, 0</td><td>see (2)</td></tr><tr><td id="long"><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#long">long</a></td><td>-9223372036854775808, ... -1, 0, 1, ... 9223372036854775807</td><td>see (2)</td></tr><tr><td id="unsignedLong"><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#unsignedLong">unsignedLong</a></td><td>0, 1, ... 18446744073709551615</td><td>see (2)</td></tr><tr><td id="int"><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#int">int</a></td><td>-2147483648, ... -1, 0, 1, ... 2147483647</td><td>see (2)</td></tr><tr><td id="unsignedInt"><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#unsignedInt">unsignedInt</a></td><td>0, 1, ...4294967295</td><td>see (2)</td></tr><tr><td id="short"><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#short">short</a></td><td>-32768, ... -1, 0, 1, ... 32767</td><td>see (2)</td></tr><tr><td id="unsignedShort"><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#unsignedShort">unsignedShort</a></td><td>0, 1, ... 65535</td><td>see (2)</td></tr><tr><td id="byte"><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#byte">byte</a></td><td>-128, ...-1, 0, 1, ... 127</td><td>see (2)</td></tr><tr><td id="unsignedByte"><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#unsignedByte">unsignedByte</a></td><td>0, 1, ... 255</td><td>see (2)</td></tr><tr><td id="decimal"><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#decimal">decimal</a></td><td>-1.23, 0, 123.4, 1000.00</td><td>see (2)</td></tr><tr><td id="float"><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#float">float</a></td><td>-INF, -1E4, -0, 0, 12.78E-2, 12, INF, NaN</td><td>equivalent to single-precision 32-bit floating point, NaN is "not a number", see (2)</td></tr><tr><td id="double"><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#double">double</a></td><td>-INF, -1E4, -0, 0, 12.78E-2, 12, INF, NaN</td><td>equivalent to double-precision 64-bit floating point, see (2)</td></tr><tr><td id="boolean"><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#boolean">boolean</a></td><td>true, false, 1, 0</td><td/></tr><tr><td id="duration"><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#duration">duration</a></td><td>P1Y2M3DT10H30M12.3S</td><td>1 year, 2 months, 3 days, 10 hours, 30 minutes, and 12.3 seconds</td></tr><tr><td id="dateTime"><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#dateTime">dateTime</a></td><td>1999-05-31T13:20:00.000-05:00</td><td>May 31st 1999 at 1.20pm Eastern Standard Time which
|
|
is 5 hours behind Co-Ordinated Universal Time, see
|
|
(2)</td></tr><tr><td id="date"><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#date">date</a></td><td>1999-05-31</td><td>see (2)</td></tr><tr><td id="time"><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#time">time</a></td><td>13:20:00.000, 13:20:00.000-05:00</td><td>see (2)</td></tr><tr><td id="gYear"><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#gYear">
|
|
gYear</a></td><td>1999</td><td>1999, see (2) (5)</td></tr><tr><td id="gYearMonth"><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#gYearMonth">gYearMonth</a></td><td>1999-02</td><td>the month of February 1999, regardless of the number of days, see (2) (5)</td></tr><tr><td id="gMonth"><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#gMonth">gMonth</a></td><td>--05</td><td>May, see (2) (5)</td></tr><tr><td id="gMonthDay"><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#gMonthDay">gMonthDay</a></td><td>--05-31</td><td>every May 31st, see (2) (5)</td></tr><tr><td id="gDay">
|
|
<a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#gDay">gDay</a></td><td>---31</td><td>the 31st day, see (2) (5)</td></tr><tr><td id="Name"><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#Name">Name</a></td><td>shipTo</td><td>XML 1.0 Name type</td></tr><tr><td id="QName"><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#QName">QName</a></td><td>po:USAddress</td><td>XML Namespace QName</td></tr><tr><td id="NCName"><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#NCName">NCName</a></td><td>USAddress</td><td>XML Namespace NCName, i.e. a QName without the prefix and colon</td></tr><tr><td id="anyURI"><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#anyURI">anyURI</a></td><td>
|
|
<table border="0"><tbody><tr><td>http://www.example.com/,</td></tr><tr><td>http://www.example.com/doc.html#ID5</td></tr></tbody></table>
|
|
</td><td/></tr><tr><td id="language"><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#language">language</a></td><td>en-GB, en-US, fr</td><td>valid values for xml:lang as defined in XML 1.0</td></tr><tr><td id="ID"><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#ID">ID</a></td><td/><td>XML 1.0 ID attribute type, see (1)</td></tr><tr><td id="IDREF"><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#IDREF">IDREF</a></td><td/><td>XML 1.0 IDREF attribute type, see (1)</td></tr><tr><td id="IDREFS"><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#IDREFS">IDREFS</a></td><td/><td>XML 1.0 IDREFS attribute type, see (1)</td></tr><tr><td id="ENTITY"><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#ENTITY">ENTITY</a></td><td/><td>XML 1.0 ENTITY attribute type, see (1)</td></tr><tr><td id="ENTITIES"><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#ENTITIES">ENTITIES</a></td><td/><td>XML 1.0 ENTITIES attribute type, see (1)</td></tr><tr><td id="NOTATION"><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#NOTATION">NOTATION</a></td><td/><td>XML 1.0 NOTATION attribute type, see (1)</td></tr><tr><td id="NMTOKEN"><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#NMTOKEN">NMTOKEN</a></td><td>
|
|
<table border="0"><tbody><tr><td>US,</td></tr><tr><td>Brésil</td></tr></tbody></table>
|
|
</td><td>XML 1.0 NMTOKEN attribute type, see (1)</td></tr><tr><td id="NMTOKENS"><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#NMTOKENS">NMTOKENS</a></td><td>
|
|
<table border="0"><tbody><tr><td>US UK,</td></tr><tr><td>Brésil Canada Mexique</td></tr></tbody></table>
|
|
</td><td>XML 1.0 NMTOKENS attribute type, i.e. a whitespace
|
|
separated list of NMTOKEN's, see (1)</td></tr><tr><td colspan="3">
|
|
Notes: (1) To retain compatibility
|
|
between XML Schema and XML 1.0 DTDs, the simple types
|
|
ID, IDREF, IDREFS, ENTITY, ENTITIES, NOTATION,
|
|
NMTOKEN, NMTOKENS should only be used in attributes.
|
|
(2) A value of this type can be represented by more
|
|
than one lexical format, e.g. 100 and 1.0E2 are both
|
|
valid float formats representing "one hundred".
|
|
However, rules have been established for this type
|
|
that define a canonical lexical format, see <a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#canonical-lexical-representation">
|
|
XML Schema Part 2</a>. (3) Newline, tab and
|
|
carriage-return characters in a normalizedString type are
|
|
converted to space characters before schema
|
|
processing. (4) As normalizedString, and adjacent space
|
|
characters are collapsed to a single space character,
|
|
and leading and trailing spaces are removed. (5) The "g"
|
|
prefix signals time periods in the Gregorian calendar.</td></tr></tbody></table><p id="ref7">New simple types are defined by
|
|
deriving them from existing simple types (built-in's and
|
|
derived). In particular, we can derive a new simple type by
|
|
restricting an existing simple type, in other words, the
|
|
legal range of values for the new type are a subset of the
|
|
existing type's range of values. We use the <code><a href="#element-simpleType">simpleType</a></code> element to
|
|
define and name the new simple type. We use the <code><a href="#element-restriction">restriction</a></code> element
|
|
to indicate the existing (base) type, and to identify the
|
|
"facets" that constrain the range of values. A complete
|
|
list of facets is provided in <a href="#SimpleTypeFacets">
|
|
Appendix B</a>.
|
|
</p><p id="ref8">Suppose we wish to create a new type
|
|
of integer called <code>myInteger</code> whose range of
|
|
values is between 10000 and 99999 (inclusive). We base our
|
|
definition on the built-in simple type <code><a href="#integer">integer</a></code>, whose range of values also
|
|
includes integers less than 10000 and greater than 99999.
|
|
To define <code>myInteger</code>, we restrict the range of
|
|
the <code><a href="#integer">integer</a></code> base type
|
|
by employing two facets called <code><a href="#element-minInclusive">minInclusive</a></code> and <code>
|
|
<a href="#element-maxInclusive">maxInclusive</a></code>:
|
|
</p><div class="exampleOuter"><a id="DefiningmyInteger" name="DefiningmyInteger"/><div class="exampleHeader">Example</div><div class="exampleWrapper">Defining myInteger, Range 10000-99999</div><div class="exampleInner"><pre>
|
|
<xsd:simpleType name="myInteger">
|
|
<xsd:restriction base="xsd:integer">
|
|
<xsd:minInclusive value="10000"/>
|
|
<xsd:maxInclusive value="99999"/>
|
|
</xsd:restriction>
|
|
</xsd:simpleType>
|
|
</pre></div></div><p>
|
|
The example shows one particular combination of a base
|
|
type and two facets used to define <code>myInteger</code>,
|
|
but a look at the list of built-in simple types and their
|
|
facets (<a href="#SimpleTypeFacets">Appendix B</a>) should
|
|
suggest other viable combinations.
|
|
</p><p id="ref9">The purchase order schema contains
|
|
another, more elaborate, example of a simple type
|
|
definition. A new simple type called <code>SKU</code> is
|
|
derived (by restriction) from the simple type <code><a href="#string"> string</a></code>. Furthermore, we
|
|
constrain the values of <code>SKU</code> using a facet
|
|
called <code><a href="#element-pattern">pattern</a></code>
|
|
in conjunction with the regular expression
|
|
"<code>\d{3}-[A-Z]{2}</code>" that is read "three digits
|
|
followed by a hyphen followed by two upper-case ASCII
|
|
letters":
|
|
</p><div class="exampleOuter"><a id="DefiningSKU" name="DefiningSKU"/><div class="exampleHeader">Example</div><div class="exampleWrapper">Defining the Simple Type "SKU"</div><div class="exampleInner"><pre>
|
|
<xsd:simpleType name="SKU">
|
|
<xsd:restriction base="xsd:string">
|
|
<xsd:pattern value="\d{3}-[A-Z]{2}"/>
|
|
</xsd:restriction>
|
|
</xsd:simpleType>
|
|
</pre></div></div><p>
|
|
This regular expression language is described more fully
|
|
in <a href="#regexAppendix">Appendix D</a>.
|
|
</p><p id="ref10">XML Schema defines twelve facets
|
|
which are listed in <a href="#SimpleTypeFacets"> Appendix
|
|
B</a>. Among these, the <code><a href="#element-enumeration">enumeration</a></code> facet is
|
|
particularly useful and it can be used to constrain the
|
|
values of almost every simple type, except the <code><a href="#boolean">boolean</a></code> type. The <code><a href="#element-enumeration">enumeration</a></code> facet limits
|
|
a simple type to a set of distinct values. For example, we
|
|
can use the <code> <a href="#element-enumeration">
|
|
enumeration</a></code> facet to define a new simple type
|
|
called <code>USState</code>, derived from <code> <a href="#string">string</a></code>, whose value must be one of the
|
|
standard US state abbreviations:
|
|
</p><div class="exampleOuter"><a id="UsingEnumeration" name="UsingEnumeration"/><div class="exampleHeader">Example</div><div class="exampleWrapper">Using the Enumeration Facet</div><div class="exampleInner"><pre>
|
|
<xsd:simpleType name="USState">
|
|
<xsd:restriction base="xsd:string">
|
|
<xsd:enumeration value="AK"/>
|
|
<xsd:enumeration value="AL"/>
|
|
<xsd:enumeration value="AR"/>
|
|
<!-- and so on ... -->
|
|
</xsd:restriction>
|
|
</xsd:simpleType>
|
|
</pre></div></div><p>
|
|
<code>USState</code> would be a good replacement for the
|
|
<code><a href="#string">string</a></code> type currently
|
|
used in the <code>state</code> element declaration. By
|
|
making this replacement, the legal values of a <code>
|
|
state</code> element, i.e. the <code> state</code>
|
|
subelements of <code>billTo</code> and <code>
|
|
shipTo</code>, would be limited to one of <code>AK</code>,
|
|
<code>AL</code>, <code>AR</code>, etc. Note that the
|
|
enumeration values specified for a particular type must be
|
|
unique.
|
|
</p><div class="div3">
|
|
<h4><a id="ListDt" name="ListDt"/>2.3.1 List Types</h4><p>
|
|
XML Schema has the concept of a list type, in addition to
|
|
the so-called atomic types that constitute most of the
|
|
types listed in <a href="#simpleTypesTable">Table 2</a>.
|
|
(Atomic types, list types, and the union types described in
|
|
the next section are collectively called simple types.) The
|
|
value of an atomic type is indivisible from XML Schema's
|
|
perspective. For example, the <code><a href="#NMTOKEN">
|
|
NMTOKEN</a></code> value <code>US</code> is indivisible in
|
|
the sense that no part of <code>US</code>, such as the
|
|
character "S", has any meaning by itself. In contrast, list
|
|
types are comprised of sequences of atomic types and
|
|
consequently the parts of a sequence (the "atoms")
|
|
themselves are meaningful. For example, <code><a href="#NMTOKENS">NMTOKENS</a></code> is a list type, and an
|
|
element of this type would be a white-space delimited list
|
|
of <code><a href="#NMTOKEN"> NMTOKEN</a></code>'s, such as
|
|
"US UK FR". XML Schema has three built-in list types, they
|
|
are <code> <a href="#NMTOKENS"> NMTOKENS</a></code>, <code>
|
|
<a href="#IDREFS"> IDREFS</a></code>, and <code> <a href="#ENTITIES"> ENTITIES</a></code>.
|
|
</p><p id="ref45">In addition to using the built-in
|
|
list types, you can create new list types by derivation
|
|
from existing atomic types. (You cannot create list types
|
|
from existing list types, nor from complex types.) For
|
|
example, to create a list of <code>myInteger</code>'s:
|
|
</p><div class="exampleOuter"><a id="CreatingListOfIntegers" name="CreatingListOfIntegers"/><div class="exampleHeader">Example</div><div class="exampleWrapper">Creating a List of myInteger's</div><div class="exampleInner"><pre>
|
|
<xsd:simpleType name="listOfMyIntType">
|
|
<xsd:list itemType="myInteger"/>
|
|
</xsd:simpleType>
|
|
</pre></div></div><p>
|
|
And an element in an instance document whose content
|
|
conforms to <code>listOfMyIntType</code> is:
|
|
</p><div class="exampleOuter"><div class="exampleHeader">Example</div><div class="exampleInner"><pre>
|
|
<listOfMyInt>20003 15037 95977 95945</listOfMyInt>
|
|
</pre></div></div><p id="ref12">Several facets can be applied to list
|
|
types: <code><a href="#element-length">length</a></code>,
|
|
<code><a href="#element-minLength">minLength</a></code>,
|
|
<code><a href="#element-maxLength">maxLength</a></code>, <code><a href="#element-pattern">pattern</a></code>,
|
|
and <code><a href="#element-enumeration">
|
|
enumeration</a></code>. For example, to define a list of
|
|
exactly six US states (<code>SixUSStates</code>), we first
|
|
define a new list type called <code>USStateList</code> from
|
|
<code>USState</code>, and then we derive <code>
|
|
SixUSStates</code> by restricting <code>USStateList</code>
|
|
to only six items:
|
|
</p><div class="exampleOuter"><a id="ListTypeFor6States" name="ListTypeFor6States"/><div class="exampleHeader">Example</div><div class="exampleWrapper">List Type for Six US States</div><div class="exampleInner"><pre>
|
|
<xsd:simpleType name="USStateList">
|
|
<xsd:list itemType="USState"/>
|
|
</xsd:simpleType>
|
|
|
|
<xsd:simpleType name="SixUSStates">
|
|
<xsd:restriction base="USStateList">
|
|
<xsd:length value="6"/>
|
|
</xsd:restriction>
|
|
</xsd:simpleType>
|
|
</pre></div></div><p>
|
|
Elements whose type is <code>SixUSStates</code> must have
|
|
six items, and each of the six items must be one of the
|
|
(atomic) values of the enumerated type <code>
|
|
USState</code>, for example:
|
|
</p><div class="exampleOuter"><div class="exampleHeader">Example</div><div class="exampleInner"><pre>
|
|
<sixStates>PA NY CA NY LA AK</sixStates>
|
|
</pre></div></div><p>
|
|
Note that it is possible to derive a list type from the
|
|
atomic type <code><a href="#string">string</a></code>.
|
|
However, a <code> <a href="#string">string</a></code> may
|
|
contain white space, and white space delimits the items in
|
|
a list type, so you should be careful using
|
|
list types whose base type is <code> <a href="#string">
|
|
string</a></code>. For example, suppose we have defined a
|
|
list type with a <code><a href="#element-length">
|
|
length</a></code> facet equal to 3, and base type <code><a href="#string">string</a></code>, then the following 3 item
|
|
list is legal:
|
|
</p><div class="exampleOuter"><div class="exampleHeader">Example</div><div class="exampleInner"><pre>
|
|
Asie Europe Afrique
|
|
</pre></div></div><p>
|
|
But the following 3 "item" list is illegal:
|
|
</p><div class="exampleOuter"><div class="exampleHeader">Example</div><div class="exampleInner"><pre>
|
|
Asie Europe Amérique Latine</pre></div></div><p>
|
|
Even though "Amérique Latine" may exist as a single
|
|
string outside of the list, when it is included in the
|
|
list, the whitespace between Amérique and Latine
|
|
effectively creates a fourth item, and so the latter
|
|
example will not conform to the 3-item list type.
|
|
</p></div><div class="div3">
|
|
<h4><a id="UnionDt" name="UnionDt"/>2.3.2 Union Types</h4><p id="ref46">Atomic types and list types enable an
|
|
element or an attribute value to be one or more instances
|
|
of one atomic type. In contrast, a union type enables an
|
|
element or attribute value to be one or more instances of
|
|
one type drawn from the union of multiple atomic and list
|
|
types. To illustrate, we create a union type for
|
|
representing American states as singleton letter
|
|
abbreviations or lists of numeric codes. The <code>
|
|
zipUnion</code> union type is built from one atomic type and
|
|
one list type:
|
|
</p><div class="exampleOuter"><a id="UnionTypeForZipCodes" name="UnionTypeForZipCodes"/><div class="exampleHeader">Example</div><div class="exampleWrapper">Union Type for Zip Codes</div><div class="exampleInner"><pre>
|
|
<xsd:simpleType name="zipUnion">
|
|
<xsd:union memberTypes="USState listOfMyIntType"/>
|
|
</xsd:simpleType>
|
|
</pre></div></div><p>
|
|
When we define a union type, the <code>memberTypes</code>
|
|
attribute value is a list of all the types in the union.
|
|
</p><p>
|
|
Now, assuming we have declared an element called <code>
|
|
zips</code> of type <code>zipUnion</code>, valid instances
|
|
of the element are:
|
|
</p><div class="exampleOuter"><div class="exampleHeader">Example</div><div class="exampleInner"><pre>
|
|
<zips>CA</zips>
|
|
<zips>95630 95977 95945</zips>
|
|
<zips>AK</zips>
|
|
</pre></div></div><p>
|
|
Two facets, <code><a href="#element-pattern">
|
|
pattern</a></code> and <code><a href="#element-enumeration">enumeration</a></code>, can be
|
|
applied to a union type.
|
|
</p></div></div><div class="div2">
|
|
<h3><span class="nav"><a class="nav" href="#CreatDt"><img src="previous.jpg" alt="previous sub-section"/></a> <a class="nav" href="#typeContent"><img src="next.jpg" alt="next sub-section"/></a></span><a id="InlineTypDefn" name="InlineTypDefn"/>2.4 Anonymous Type Definitions</h3><p>
|
|
Schemas can be constructed by defining sets of named types
|
|
such as <code>PurchaseOrderType</code> and then declaring
|
|
elements such as <code>purchaseOrder</code> that reference
|
|
the types using the <code><a href="#attribute-type">
|
|
type</a>=</code> construction. This style of schema
|
|
construction is straightforward but it can be unwieldy,
|
|
especially if you define many types that are referenced
|
|
only once and contain very few constraints. In these cases,
|
|
a type can be more succinctly defined as an anonymous type
|
|
which saves the overhead of having to be named and
|
|
explicitly referenced.
|
|
</p><p>
|
|
The definition of the type <code>Items</code> in <code> <a href="#po.xsd">po.xsd</a></code> contains two element
|
|
declarations that use anonymous types (<code>item</code>
|
|
and <code> quantity</code>). In general, you can identify
|
|
anonymous types by the lack of a <code><a href="#attribute-type">type</a>=</code> in an element (or
|
|
attribute) declaration, and by the presence of an un-named
|
|
(simple or complex) type definition:
|
|
</p><div class="exampleOuter"><a id="TwoAnonymousTypeDefinitions" name="TwoAnonymousTypeDefinitions"/><div class="exampleHeader">Example</div><div class="exampleWrapper">Two Anonymous Type Definitions</div><div class="exampleInner"><pre>
|
|
<xsd:complexType name="Items">
|
|
<xsd:sequence>
|
|
<xsd:element name="item" minOccurs="0" maxOccurs="unbounded">
|
|
<xsd:complexType>
|
|
<xsd:sequence>
|
|
<xsd:element name="productName" type="xsd:string"/>
|
|
<xsd:element name="quantity">
|
|
<xsd:simpleType>
|
|
<xsd:restriction base="xsd:positiveInteger">
|
|
<xsd:maxExclusive value="100"/>
|
|
</xsd:restriction>
|
|
</xsd:simpleType>
|
|
</xsd:element>
|
|
<xsd:element name="USPrice" type="xsd:decimal"/>
|
|
<xsd:element ref="comment" minOccurs="0"/>
|
|
<xsd:element name="shipDate" type="xsd:date" minOccurs="0"/>
|
|
</xsd:sequence>
|
|
<xsd:attribute name="partNum" type="SKU" use="required"/>
|
|
</xsd:complexType>
|
|
</xsd:element>
|
|
</xsd:sequence>
|
|
</xsd:complexType>
|
|
</pre></div></div><p>
|
|
In the case of the <code>item</code> element, it has an
|
|
anonymous complex type consisting of the elements <code>
|
|
productName</code>, <code>quantity</code>, <code>
|
|
USPrice</code>, <code>comment</code>, and <code>
|
|
shipDate</code>, and an attribute called <code>
|
|
partNum</code>. In the case of the <code>quantity</code>
|
|
element, it has an anonymous simple type derived from
|
|
|
|
<code><a href="#positiveInteger">positiveInteger</a></code> whose value
|
|
ranges between 1 and 99.
|
|
</p></div><div class="div2">
|
|
<h3 class="withToc"><span class="nav"><a class="nav" href="#InlineTypDefn"><img src="previous.jpg" alt="previous sub-section"/></a> <a class="nav" href="#CommVers"><img src="next.jpg" alt="next sub-section"/></a></span><a id="typeContent" name="typeContent"/>2.5 Element Content</h3><div class="localToc">        2.5.1 <a href="#complexTfromSimpleT">Complex Types from Simple Types</a><br/>
|
|
        2.5.2 <a href="#mixedContent">Mixed Content</a><br/>
|
|
        2.5.3 <a href="#emptyContent">Empty Content</a><br/>
|
|
        2.5.4 <a href="#anyType">anyType</a><br/>
|
|
</div><p>
|
|
The purchase order schema has many examples of elements
|
|
containing other elements (e.g. <code>items</code>),
|
|
elements having attributes and containing other elements
|
|
(e.g. <code>shipTo</code>), and elements containing only a
|
|
simple type of value (e.g. <code>USPrice</code>). However,
|
|
we have not seen an element having attributes but
|
|
containing only a simple type of value, nor have we seen an
|
|
element that contains other elements mixed with character
|
|
content, nor have we seen an element that has no content at
|
|
all. In this section we'll examine these variations in the
|
|
content models of elements.
|
|
</p><div class="div3">
|
|
<h4><a id="complexTfromSimpleT" name="complexTfromSimpleT"/>2.5.1 Complex Types from Simple Types</h4><p>
|
|
Let us first consider how to declare an element that has
|
|
an attribute and contains a simple value. In an instance
|
|
document, such an element might appear as:
|
|
</p><div class="exampleOuter"><div class="exampleHeader">Example</div><div class="exampleInner"><pre>
|
|
<internationalPrice currency="EUR">423.46</internationalPrice>
|
|
</pre></div></div><p>
|
|
The purchase order schema declares a <code>USPrice</code>
|
|
element that is a starting point:
|
|
</p><div class="exampleOuter"><div class="exampleHeader">Example</div><div class="exampleInner"><pre>
|
|
<xsd:element name="USPrice" type="decimal"/>
|
|
</pre></div></div><p id="ref37">Now, how do we add an attribute to
|
|
this element? As we have said before, simple types cannot
|
|
have attributes, and <code><a href="#decimal">
|
|
decimal</a></code> is a simple type. Therefore, we must
|
|
define a complex type to carry the attribute declaration.
|
|
We also want the content to be simple type <code> <a href="#decimal">decimal</a></code>. So our original question
|
|
becomes: How do we define a complex type that is based on
|
|
the simple type <code><a href="#decimal">
|
|
decimal</a></code>? The answer is to <em>derive</em> a new
|
|
complex type from the simple type <code><a href="#decimal">
|
|
decimal</a></code>:
|
|
</p><div class="exampleOuter"><a id="DerivingAComplexType" name="DerivingAComplexType"/><div class="exampleHeader">Example</div><div class="exampleWrapper">Deriving a Complex Type from a Simple Type</div><div class="exampleInner"><pre>
|
|
<xsd:element name="internationalPrice">
|
|
<xsd:complexType>
|
|
<xsd:simpleContent>
|
|
<xsd:extension base="xsd:decimal">
|
|
<xsd:attribute name="currency" type="xsd:string"/>
|
|
</xsd:extension>
|
|
</xsd:simpleContent>
|
|
</xsd:complexType>
|
|
</xsd:element>
|
|
</pre></div></div><p>
|
|
We use the <code><a href="#element-complexType">
|
|
complexType</a></code> element to start the definition of a
|
|
new (anonymous) type. To indicate that the content model of
|
|
the new type contains only character data and no elements,
|
|
we use a <code><a href="#element-simpleContent">
|
|
simpleContent</a></code> element. Finally, we derive the
|
|
new type by extending the simple <code><a href="#decimal">
|
|
decimal</a></code> type. The extension consists of adding a
|
|
<code>currency</code> attribute using a standard attribute
|
|
declaration. (We cover type derivation in detail in <a href="#IPO">Advanced Concepts II: The International Purchase Order (§4)</a>.) The <code>
|
|
internationalPrice</code> element declared in this way will
|
|
appear in an instance as shown in the example at the
|
|
beginning of this section.
|
|
</p></div><div class="div3">
|
|
<h4><a id="mixedContent" name="mixedContent"/>2.5.2 Mixed Content</h4><p id="ref51">The construction of the purchase order schema may be
|
|
characterized as elements containing subelements, and the
|
|
deepest subelements contain character data. XML Schema also
|
|
provides for the construction of schemas where character
|
|
data can appear alongside subelements, and character data
|
|
is not confined to the deepest subelements.
|
|
</p><p>
|
|
To illustrate, consider the following snippet from a
|
|
customer letter that uses some of the same elements as the
|
|
purchase order:
|
|
</p><div class="exampleOuter"><a id="SnippetOfCustomerLetter" name="SnippetOfCustomerLetter"/><div class="exampleHeader">Example</div><div class="exampleWrapper">Snippet of Customer Letter</div><div class="exampleInner"><pre>
|
|
<letterBody>
|
|
<salutation>Dear Mr.<name>Robert Smith</name>.</salutation>
|
|
Your order of <quantity>1</quantity> <productName>Baby
|
|
Monitor</productName> shipped from our warehouse on
|
|
<shipDate>1999-05-21</shipDate>. ....
|
|
</letterBody>
|
|
</pre></div></div><p>
|
|
Notice the text appearing between elements and their child
|
|
elements. Specifically, text appears between the elements
|
|
<code>salutation</code>, <code>quantity</code>, <code>
|
|
productName</code> and <code>shipDate</code> which are all
|
|
children of <code>letterBody</code>, and text appears
|
|
around the element <code>name</code>
|
|
which is the child of a child of
|
|
<code>letterBody</code>. The following snippet of a schema
|
|
declares <code>letterBody</code>:
|
|
</p><div class="exampleOuter"><a id="SnippetOfCustomerLetterSchema" name="SnippetOfCustomerLetterSchema"/><div class="exampleHeader">Example</div><div class="exampleWrapper">Snippet of Schema for Customer Letter</div><div class="exampleInner"><pre>
|
|
<xsd:element name="letterBody">
|
|
<xsd:complexType mixed="true">
|
|
<xsd:sequence>
|
|
<xsd:element name="salutation">
|
|
<xsd:complexType mixed="true">
|
|
<xsd:sequence>
|
|
<xsd:element name="name" type="xsd:string"/>
|
|
</xsd:sequence>
|
|
</xsd:complexType>
|
|
</xsd:element>
|
|
<xsd:element name="quantity" type="xsd:positiveInteger"/>
|
|
<xsd:element name="productName" type="xsd:string"/>
|
|
<xsd:element name="shipDate" type="xsd:date" minOccurs="0"/>
|
|
<!-- etc. -->
|
|
</xsd:sequence>
|
|
</xsd:complexType>
|
|
</xsd:element>
|
|
</pre></div></div><p>
|
|
The elements appearing in the customer letter are
|
|
declared, and their types are defined using the <code><a href="#element-element">element</a></code> and <code><a href="#element-complexType">complexType</a></code> element
|
|
constructions we have seen before. To enable character data
|
|
to appear between the child-elements of <code>
|
|
letterBody</code>, the <code><a href="#attribute-mixed">
|
|
mixed</a></code> attribute on the type definition is set to
|
|
true.
|
|
</p><p>
|
|
Note that the <code>mixed</code> model in XML Schema
|
|
differs fundamentally from the <a href="http://www.w3.org/TR/2000/REC-xml-20001006#sec-mixed-content">
|
|
mixed model in XML 1.0</a>. Under the XML Schema
|
|
mixed model, the order and number of child elements
|
|
appearing in an instance must agree with the order and
|
|
number of child elements specified in the model. In
|
|
contrast, under the XML 1.0 mixed model, the order and
|
|
number of child elements appearing in an instance cannot be
|
|
constrained. In summary, XML Schema provides full validation of
|
|
mixed models in contrast to the partial schema validation
|
|
provided by XML 1.0.
|
|
</p></div><div class="div3">
|
|
<h4><a id="emptyContent" name="emptyContent"/>2.5.3 Empty Content</h4><p>
|
|
Now suppose that we want the <code>
|
|
internationalPrice</code> element to convey both the unit
|
|
of currency and the price as attribute values rather than
|
|
as separate attribute and content values. For example:
|
|
</p><div class="exampleOuter"><div class="exampleHeader">Example</div><div class="exampleInner"><pre>
|
|
<internationalPrice currency="EUR" value="423.46"/>
|
|
</pre></div></div><p id="ref13">Such an element has no content at
|
|
all; its content model is empty. To define a type whose
|
|
content is empty, we essentially define a type that allows
|
|
only elements in its content, but we do not actually
|
|
declare any elements and so the type's content model is
|
|
empty:
|
|
</p><div class="exampleOuter"><a id="AnEmptyComplexType" name="AnEmptyComplexType"/><div class="exampleHeader">Example</div><div class="exampleWrapper">An Empty Complex Type</div><div class="exampleInner"><pre>
|
|
<xsd:element name="internationalPrice">
|
|
<xsd:complexType>
|
|
<xsd:complexContent>
|
|
<xsd:restriction base="xsd:anyType">
|
|
<xsd:attribute name="currency" type="xsd:string"/>
|
|
<xsd:attribute name="value" type="xsd:decimal"/>
|
|
</xsd:restriction>
|
|
</xsd:complexContent>
|
|
</xsd:complexType>
|
|
</xsd:element>
|
|
</pre></div></div><p>
|
|
In this example, we define an (anonymous) type having
|
|
<code>complexContent</code>, i.e. only elements. The <code>
|
|
complexContent</code> element signals that we intend to
|
|
restrict or extend the content model of a complex type, and the
|
|
<code>restriction</code> of <code>anyType</code> declares
|
|
two attributes but does not introduce any element content
|
|
(see <a href="#DerivByRestrict">Deriving Complex Types by Restriction (§4.4)</a> for more
|
|
details on restriction). The <code>
|
|
internationalPrice</code> element declared in this way may
|
|
legitimately appear in an instance as shown in the example
|
|
above.
|
|
</p><p>
|
|
The preceding syntax for an empty-content element is
|
|
relatively verbose, and it is possible to declare the
|
|
<code>internationalPrice</code> element more compactly:
|
|
</p><div class="exampleOuter"><a id="ShorthandForAnEmptyComplexType" name="ShorthandForAnEmptyComplexType"/><div class="exampleHeader">Example</div><div class="exampleWrapper">Shorthand for an Empty Complex Type</div><div class="exampleInner"><pre>
|
|
<xsd:element name="internationalPrice">
|
|
<xsd:complexType>
|
|
<xsd:attribute name="currency" type="xsd:string"/>
|
|
<xsd:attribute name="value" type="xsd:decimal"/>
|
|
</xsd:complexType>
|
|
</xsd:element>
|
|
</pre></div></div><p>
|
|
This compact syntax works because a complex type defined
|
|
without any <code>simpleContent</code> or <code>
|
|
complexContent</code> is interpreted as shorthand for
|
|
complex content that restricts <code>anyType</code>.
|
|
</p></div><div class="div3">
|
|
<h4><a id="anyType" name="anyType"/>2.5.4 anyType</h4><p>
|
|
The <code>anyType</code> represents an abstraction called
|
|
the <a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#Type_Derivation">
|
|
ur-type</a> which is the base type from which all
|
|
simple and complex types are derived. An <code>
|
|
anyType</code> type does not constrain its content in any
|
|
way. It is possible to use <code>anyType</code> like other
|
|
types, for example:
|
|
</p><div class="exampleOuter"><div class="exampleHeader">Example</div><div class="exampleInner"><pre>
|
|
<xsd:element name="anything" type="xsd:anyType"/>
|
|
</pre></div></div><p>
|
|
The content of the element declared in this way is
|
|
unconstrained, so the element value may be 423.46, but it
|
|
may be any other sequence of characters as well, or indeed
|
|
a mixture of characters and elements. In fact, <code>
|
|
anyType</code> is the default type when none is specified,
|
|
so the above could also be written as follows:
|
|
</p><div class="exampleOuter"><div class="exampleHeader">Example</div><div class="exampleInner"><pre>
|
|
<xsd:element name="anything"/>
|
|
</pre></div></div><p>
|
|
If unconstrained element content is needed, for example in
|
|
the case of elements containing prose which requires embedded
|
|
markup to support internationalization, then the default
|
|
declaration or a slightly restricted form of it may be suitable.
|
|
The <code>text</code> type described in <a href="#any">Any Element, Any Attribute (§5.5)</a>
|
|
is an example of such a type that is suitable for such
|
|
purposes.
|
|
</p></div></div><div class="div2">
|
|
<h3><span class="nav"><a class="nav" href="#typeContent"><img src="previous.jpg" alt="previous sub-section"/></a> <a class="nav" href="#groups"><img src="next.jpg" alt="next sub-section"/></a></span><a id="CommVers" name="CommVers"/>2.6 Annotations</h3><p id="ref14">XML Schema provides three elements
|
|
for annotating schemas for the benefit of both human
|
|
readers and applications. In the purchase order schema, we
|
|
put a basic schema description and copyright information
|
|
inside the <code><a href="#element-documentation">
|
|
documentation</a></code> element, which is the recommended
|
|
location for human readable material. We recommend you use
|
|
the <code>xml:lang</code> attribute with any
|
|
<code><a href="#element-documentation">documentation</a></code>
|
|
elements to indicate the language of the information. Alternatively,
|
|
you may indicate the language of all information in a schema by placing
|
|
an <code>xml:lang</code> attribute on the <code>schema</code> element.
|
|
</p><p id="ref15">The <code><a href="#element-appinfo">appinfo</a></code> element, which we did not use in the
|
|
purchase order schema, can be used to provide information
|
|
for tools, stylesheets and other applications. An
|
|
interesting example using <code><a href="#element-appinfo">appinfo</a></code> is a
|
|
<a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#schema">schema</a>
|
|
that describes
|
|
the simple types in XML Schema Part 2: Datatypes.
|
|
Information describing this schema, e.g. which facets are
|
|
applicable to particular simple types, is represented
|
|
inside <code><a href="#element-appinfo">appinfo</a></code>
|
|
elements, and this information was used by an application to automatically
|
|
generate text for the XML Schema Part 2 document.
|
|
</p><p id="ref16">Both <code><a href="#element-documentation">documentation</a></code> and
|
|
<code><a href="#element-appinfo">appinfo</a></code> appear
|
|
as subelements of <code><a href="#element-annotation">
|
|
annotation</a></code>, which may itself appear at the
|
|
beginning of most schema constructions. To illustrate, the
|
|
following example shows <code><a href="#element-annotation">annotation</a></code> elements
|
|
appearing at the beginning of an element declaration and a
|
|
complex type definition:
|
|
</p><div class="exampleOuter"><a id="AnnotationsInElementDeclaration" name="AnnotationsInElementDeclaration"/><div class="exampleHeader">Example</div><div class="exampleWrapper">Annotations in Element Declaration & Complex Type Definition</div><div class="exampleInner"><pre>
|
|
<xsd:element name="internationalPrice">
|
|
<xsd:annotation>
|
|
<xsd:documentation xml:lang="en">
|
|
element declared with anonymous type
|
|
</xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:complexType>
|
|
<xsd:annotation>
|
|
<xsd:documentation xml:lang="en">
|
|
empty anonymous type with 2 attributes
|
|
</xsd:documentation>
|
|
</xsd:annotation>
|
|
<xsd:complexContent>
|
|
<xsd:restriction base="xsd:anyType">
|
|
<xsd:attribute name="currency" type="xsd:string"/>
|
|
<xsd:attribute name="value" type="xsd:decimal"/>
|
|
</xsd:restriction>
|
|
</xsd:complexContent>
|
|
</xsd:complexType>
|
|
</xsd:element>
|
|
</pre></div></div><p>
|
|
The <code><a href="#element-annotation">
|
|
annotation</a></code> element may also appear at the
|
|
beginning of other schema constructions such as those
|
|
indicated by the elements <code><a href="#element-schema">
|
|
schema</a></code>, <code><a href="#element-simpleType">
|
|
simpleType</a></code>, and <code><a href="#element-attribute">attribute</a></code>.
|
|
</p></div><div class="div2">
|
|
<h3><span class="nav"><a class="nav" href="#CommVers"><img src="previous.jpg" alt="previous sub-section"/></a> <a class="nav" href="#AttrGroups"><img src="next.jpg" alt="next sub-section"/></a></span><a id="groups" name="groups"/>2.7 Building Content Models</h3><p>
|
|
The definitions of complex types in the purchase order
|
|
schema all declare sequences of elements that must appear
|
|
in the instance document. The occurrence of individual
|
|
elements declared in the so-called content models of these
|
|
types may be optional, as indicated by a 0 value for the
|
|
attribute <code><a href="#attribute-minOccurs">
|
|
minOccurs</a></code> (e.g. in <code> comment</code>), or be
|
|
otherwise constrained depending upon the values of <code><a href="#attribute-minOccurs">minOccurs</a></code> and <code>
|
|
<a href="#attribute-maxOccurs">maxOccurs</a></code>. XML
|
|
Schema also provides constraints that apply to groups of
|
|
elements appearing in a content model. These constraints
|
|
mirror those available in XML 1.0 plus some additional
|
|
constraints. Note that the constraints do not apply to
|
|
attributes.
|
|
</p><p>
|
|
XML Schema enables groups of elements to be defined and
|
|
named, so that the elements can be used to build up the
|
|
content models of complex types (thus mimicking common
|
|
usage of parameter entities in XML 1.0). Un-named groups of
|
|
elements can also be defined, and along with elements in
|
|
named groups, they can be constrained to appear in the same
|
|
order (sequence) as they are declared. Alternatively, they
|
|
can be constrained so that only one of the elements may
|
|
appear in an instance.
|
|
</p><p id="ref17">To illustrate, we introduce two groups
|
|
into the <code>PurchaseOrderType</code> definition from the
|
|
purchase order schema so that purchase orders may contain
|
|
either separate shipping and billing addresses, or a single
|
|
address for those cases in which the shippee and billee are
|
|
co-located:
|
|
</p><div class="exampleOuter"><a id="NestedChoiceAndSequenceGroups" name="NestedChoiceAndSequenceGroups"/><div class="exampleHeader">Example</div><div class="exampleWrapper">Nested Choice and Sequence Groups</div><div class="exampleInner"><pre>
|
|
<xsd:complexType name="PurchaseOrderType">
|
|
<xsd:sequence>
|
|
<xsd:choice>
|
|
<xsd:group ref="shipAndBill"/>
|
|
<xsd:element name="singleUSAddress" type="USAddress"/>
|
|
</xsd:choice>
|
|
<xsd:element ref="comment" minOccurs="0"/>
|
|
<xsd:element name="items" type="Items"/>
|
|
</xsd:sequence>
|
|
<xsd:attribute name="orderDate" type="xsd:date"/>
|
|
</xsd:complexType>
|
|
|
|
<xsd:group id="shipAndBill">
|
|
<xsd:sequence>
|
|
<xsd:element name="shipTo" type="USAddress"/>
|
|
<xsd:element name="billTo" type="USAddress"/>
|
|
</xsd:sequence>
|
|
</xsd:group>
|
|
</pre></div></div><p>
|
|
The <code><a href="#element-choice">choice</a></code>
|
|
group element allows only one of its children to appear in
|
|
an instance. One child is an inner <code><a href="#element-group">group</a></code> element that references
|
|
the named group <code>shipAndBill</code> consisting of the
|
|
element sequence <code>shipTo</code>, <code>billTo</code>,
|
|
and the second child is a <code>singleUSAddress</code>.
|
|
Hence, in an instance document, the <code>
|
|
purchaseOrder</code> element must contain either a <code>
|
|
shipTo</code> element followed by a <code> billTo</code>
|
|
element or a <code>singleUSAddress</code> element. The
|
|
<code><a href="#element-choice">choice</a></code> group is
|
|
followed by the <code>comment</code> and <code>items</code>
|
|
element declarations, and both the <code><a href="#element-choice">choice</a></code> group and the element
|
|
declarations are children of a <code><a href="#element-sequence">sequence</a></code> group. The effect
|
|
of these various groups is that the address element(s) must
|
|
be followed by <code>comment</code> and <code>items</code>
|
|
elements in that order.
|
|
</p><p id="ref18">There exists a third option for
|
|
constraining elements in a group: All the elements in the
|
|
group may appear once or not at all, and they may appear in
|
|
any order. The <code><a href="#element-all">all</a></code>
|
|
group (which provides a simplified version of the SGML
|
|
&-Connector) is limited to the top-level of any content
|
|
model. Moreover, the group's children must all be
|
|
individual elements (no groups), and no element in the
|
|
content model may appear more than once, i.e. the
|
|
permissible values of <code><a href="#attribute-minOccurs">
|
|
minOccurs</a></code> and <code><a href="#attribute-maxOccurs">maxOccurs</a></code> are 0 and 1.
|
|
For example, to allow the child elements of <code>
|
|
purchaseOrder</code> to appear in any order, we could
|
|
redefine <code> PurchaseOrderType</code> as:
|
|
</p><div class="exampleOuter"><a id="AnAllGroup" name="AnAllGroup"/><div class="exampleHeader">Example</div><div class="exampleWrapper">An 'All' Group</div><div class="exampleInner"><pre>
|
|
<xsd:complexType name="PurchaseOrderType">
|
|
<xsd:all>
|
|
<xsd:element name="shipTo" type="USAddress"/>
|
|
<xsd:element name="billTo" type="USAddress"/>
|
|
<xsd:element ref="comment" minOccurs="0"/>
|
|
<xsd:element name="items" type="Items"/>
|
|
</xsd:all>
|
|
<xsd:attribute name="orderDate" type="xsd:date"/>
|
|
</xsd:complexType>
|
|
</pre></div></div><p>
|
|
By this definition, a <code>comment</code> element may
|
|
optionally appear within <code>purchaseOrder</code>, and it
|
|
may appear before or after any <code>shipTo</code>, <code>
|
|
billTo</code> and <code>items</code> elements, but it can
|
|
appear only once. Moreover, the stipulations of an <code><a href="#element-all">all</a></code> group do not allow us to
|
|
declare an element such as <code>comment</code> outside the
|
|
group as a means of enabling it to appear more than once.
|
|
XML Schema stipulates that an <code><a href="#element-all">
|
|
all</a></code> group must appear as the sole child at the
|
|
top of a content model. In other words, the following is
|
|
illegal:
|
|
</p><div class="exampleOuter"><a id="IllegalExampleWithAllGroup" name="IllegalExampleWithAllGroup"/><div class="exampleHeader">Example</div><div class="exampleWrapper">Illegal Example with an 'All' Group</div><div class="exampleInner"><pre>
|
|
<xsd:complexType name="PurchaseOrderType">
|
|
<xsd:sequence>
|
|
<xsd:all>
|
|
<xsd:element name="shipTo" type="USAddress"/>
|
|
<xsd:element name="billTo" type="USAddress"/>
|
|
<xsd:element name="items" type="Items"/>
|
|
</xsd:all>
|
|
<xsd:sequence>
|
|
<xsd:element ref="comment" minOccurs="0" maxOccurs="unbounded"/>
|
|
</xsd:sequence>
|
|
</xsd:sequence>
|
|
<xsd:attribute name="orderDate" type="xsd:date"/>
|
|
</xsd:complexType>
|
|
</pre></div></div><p>
|
|
Finally, named and un-named groups that appear in content
|
|
models (represented by <code><a href="#element-group">
|
|
group</a></code> and <code><a href="#element-choice">
|
|
choice</a></code>, <code><a href="#element-sequence">
|
|
sequence</a></code>, <code><a href="#element-all">
|
|
all</a></code> respectively) may carry <code><a href="#attribute-minOccurs">minOccurs</a></code> and <code><a href="#attribute-maxOccurs">maxOccurs</a></code>
|
|
attributes. By combining and nesting the various groups
|
|
provided by XML Schema, and by setting the values of <code>
|
|
<a href="#attribute-minOccurs">minOccurs</a></code> and
|
|
<code><a href="#attribute-maxOccurs">maxOccurs</a></code>,
|
|
it is possible to represent any content model expressible
|
|
with an XML 1.0 DTD. Furthermore, the <code><a href="#element-all">all</a></code> group provides additional
|
|
expressive power.
|
|
</p></div><div class="div2">
|
|
<h3><span class="nav"><a class="nav" href="#groups"><img src="previous.jpg" alt="previous sub-section"/></a> <a class="nav" href="#Nils"><img src="next.jpg" alt="next sub-section"/></a></span><a id="AttrGroups" name="AttrGroups"/>2.8 Attribute Groups</h3><p>
|
|
Suppose we want to provide more information about each
|
|
item in a purchase order, for example, each item's weight
|
|
and preferred shipping method. We can accomplish this by
|
|
adding <code>weightKg</code> and <code>shipBy</code>
|
|
attribute declarations to the <code>item</code> element's
|
|
(anonymous) type definition:
|
|
</p><div class="exampleOuter"><a id="AddingAttributesToInline" name="AddingAttributesToInline"/><div class="exampleHeader">Example</div><div class="exampleWrapper">Adding Attributes to the Inline Type Definition</div><div class="exampleInner"><pre>
|
|
<xsd:element name="item" minOccurs="0" maxOccurs="unbounded">
|
|
<xsd:complexType>
|
|
<xsd:sequence>
|
|
<xsd:element name="productName" type="xsd:string"/>
|
|
<xsd:element name="quantity">
|
|
<xsd:simpleType>
|
|
<xsd:restriction base="xsd:positiveInteger">
|
|
<xsd:maxExclusive value="100"/>
|
|
</xsd:restriction>
|
|
</xsd:simpleType>
|
|
</xsd:element>
|
|
<xsd:element name="USPrice" type="xsd:decimal"/>
|
|
<xsd:element ref="comment" minOccurs="0"/>
|
|
<xsd:element name="shipDate" type="xsd:date" minOccurs="0"/>
|
|
</xsd:sequence>
|
|
<xsd:attribute name="partNum" type="SKU" use="required"/>
|
|
<!-- add weightKg and shipBy attributes -->
|
|
<xsd:attribute name="weightKg" type="xsd:decimal"/>
|
|
<xsd:attribute name="shipBy">
|
|
<xsd:simpleType>
|
|
<xsd:restriction base="xsd:string">
|
|
<xsd:enumeration value="air"/>
|
|
<xsd:enumeration value="land"/>
|
|
<xsd:enumeration value="any"/>
|
|
</xsd:restriction>
|
|
</xsd:simpleType>
|
|
</xsd:attribute>
|
|
</xsd:complexType>
|
|
</xsd:element>
|
|
</pre></div></div><p id="ref19">Alternatively, we can create a named
|
|
attribute group containing all the desired attributes of an
|
|
<code>item</code> element, and reference this group by name
|
|
in the <code>item</code> element declaration:
|
|
</p><div class="exampleOuter"><a id="AddingAttributesUsingGroup" name="AddingAttributesUsingGroup"/><div class="exampleHeader">Example</div><div class="exampleWrapper">Adding Attributes Using an Attribute Group</div><div class="exampleInner"><pre>
|
|
<xsd:element name="item" minOccurs="0" maxOccurs="unbounded">
|
|
<xsd:complexType>
|
|
<xsd:sequence>
|
|
<xsd:element name="productName" type="xsd:string"/>
|
|
<xsd:element name="quantity">
|
|
<xsd:simpleType>
|
|
<xsd:restriction base="xsd:positiveInteger">
|
|
<xsd:maxExclusive value="100"/>
|
|
</xsd:restriction>
|
|
</xsd:simpleType>
|
|
</xsd:element>
|
|
<xsd:element name="USPrice" type="xsd:decimal"/>
|
|
<xsd:element ref="comment" minOccurs="0"/>
|
|
<xsd:element name="shipDate" type="xsd:date" minOccurs="0"/>
|
|
</xsd:sequence>
|
|
|
|
<!-- attributeGroup replaces individual declarations -->
|
|
<xsd:attributeGroup ref="ItemDelivery"/>
|
|
</xsd:complexType>
|
|
</xsd:element>
|
|
|
|
<xsd:attributeGroup id="ItemDelivery">
|
|
<xsd:attribute name="partNum" type="SKU" use="required"/>
|
|
<xsd:attribute name="weightKg" type="xsd:decimal"/>
|
|
<xsd:attribute name="shipBy">
|
|
<xsd:simpleType>
|
|
<xsd:restriction base="xsd:string">
|
|
<xsd:enumeration value="air"/>
|
|
<xsd:enumeration value="land"/>
|
|
<xsd:enumeration value="any"/>
|
|
</xsd:restriction>
|
|
</xsd:simpleType>
|
|
</xsd:attribute>
|
|
</xsd:attributeGroup>
|
|
</pre></div></div><p>
|
|
Using an attribute group in this way can improve the
|
|
readability of schemas, and facilitates updating schemas
|
|
because an attribute group can be defined and edited in one
|
|
place and referenced in multiple definitions and
|
|
declarations. These characteristics of attribute groups
|
|
make them similar to parameter entities in XML 1.0. Note
|
|
that an attribute group may contain other attribute groups.
|
|
Note also that both attribute declarations and attribute
|
|
group references must appear at the end of complex type
|
|
definitions.
|
|
</p></div><div class="div2">
|
|
<h3><span class="nav"><a class="nav" href="#AttrGroups"><img src="previous.jpg" alt="previous sub-section"/></a> </span><a id="Nils" name="Nils"/>2.9 Nil Values</h3><p>
|
|
One of the purchase order items listed in <code> <a href="#po.xml">po.xml</a></code>, the <code>Lawnmower</code>,
|
|
does not have a <code>shipDate</code> element. Within the
|
|
context of our scenario, the schema author may have
|
|
intended such absences to indicate <code>item</code>s not
|
|
yet shipped. But in general, the absence of an element does
|
|
not have any particular meaning: It may indicate that the
|
|
information is unknown, or not applicable, or the element
|
|
may be absent for some other reason. Sometimes it is
|
|
desirable to represent an unshipped <code>item</code>,
|
|
unknown information, or inapplicable information <em>
|
|
explicitly</em> with an element, rather than by an absent
|
|
element. For example, it may be desirable to represent a
|
|
"null" value being sent to or from a relational database
|
|
with an element that is present. Such cases can be
|
|
represented using XML Schema's nil mechanism which enables
|
|
an element to appear with or without a non-nil value.
|
|
</p><p id="ref20">XML Schema's nil mechanism involves
|
|
an "out of band" nil signal. In other words, there is no
|
|
actual nil value that appears as element content, instead
|
|
there is an attribute to indicate that the element content
|
|
is nil. To illustrate, we modify the <code>
|
|
shipDate</code> element declaration so that nils can be
|
|
signalled:
|
|
</p><div class="exampleOuter"><div class="exampleHeader">Example</div><div class="exampleInner"><pre>
|
|
<xsd:element name="shipDate" type="xsd:date" nillable="true"/>
|
|
</pre></div></div><p id="ref21">And to explicitly represent that
|
|
<code>shipDate</code> has a nil value in the instance
|
|
document, we set the <code><a href="#attribute-xsinil">nil</a></code>
|
|
attribute (from the XML Schema
|
|
namespace for instances) to true:
|
|
</p><div class="exampleOuter"><div class="exampleHeader">Example</div><div class="exampleInner"><pre>
|
|
<shipDate xsi:nil="true"></shipDate>
|
|
</pre></div></div><p>
|
|
The <code><a href="#attribute-xsinil">nil</a></code>
|
|
attribute is defined as part of the XML Schema namespace
|
|
for instances,
|
|
<code>http://www.w3.org/2001/XMLSchema-instance</code>,
|
|
and so it must appear in the instance document with a
|
|
prefix (such as <code>xsi:</code>) associated with that namespace.
|
|
(As with the <code>xsd:</code> prefix, the <code>
|
|
xsi:</code> prefix is used by convention only.) Note that
|
|
the nil mechanism applies only to element values, and not
|
|
to attribute values. An element with <code> <a href="#attribute-xsinil">xsi:nil</a>="true"</code> may not
|
|
have any element content but it may still carry attributes.
|
|
</p></div></div><div class="div1">
|
|
<h2><a id="NS" name="NS"/>3 Advanced Concepts I: Namespaces, Schemas & Qualification</h2><p id="ref38">A schema can be viewed as a
|
|
collection (vocabulary) of type definitions and element
|
|
declarations whose names belong to a particular namespace
|
|
called a target namespace. Target namespaces enable us
|
|
to distinguish between definitions and declarations from
|
|
different vocabularies. For example, target namespaces
|
|
would enable us to distinguish between the declaration for
|
|
<code><a href="#element-element">element</a></code> in the
|
|
XML Schema language vocabulary, and a declaration for
|
|
<code>element</code> in a hypothetical chemistry language
|
|
vocabulary. The former is part of the <code>
|
|
http://www.w3.org/2001/XMLSchema</code> target
|
|
namespace, and the latter is part of another target
|
|
namespace.
|
|
</p><p id="ref22">When we want to check that an
|
|
instance document conforms to one or more schemas (through
|
|
a process called schema validation), we need to identify
|
|
which element and attribute declarations and type
|
|
definitions in the schemas should be used to check which
|
|
elements and attributes in the instance document. The
|
|
target namespace plays an important role in the
|
|
identification process. We examine the role of the target
|
|
namespace in the next section.
|
|
</p><p>
|
|
The schema author also has several options that affect how
|
|
the identities of elements and attributes are represented
|
|
in instance documents. More specifically, the author can
|
|
decide whether or not the appearance of locally declared
|
|
elements and attributes in an instance must be qualified by
|
|
a namespace, using either an explicit prefix or implicitly
|
|
by default. The schema author's choice regarding
|
|
qualification of local elements and attributes has a number
|
|
of implications regarding the structures of schemas and
|
|
instance documents, and we examine some of these
|
|
implications in the following sections.
|
|
</p><div class="div2">
|
|
<h3><span class="nav"> <a class="nav" href="#QualLocals"><img src="next.jpg" alt="next sub-section"/></a></span><a id="UnqualLocals" name="UnqualLocals"/>3.1 Target Namespaces & Unqualified Locals</h3><p id="ref56">
|
|
In a new version of the purchase order schema, <code><a href="#po1.xsd">po1.xsd</a></code>, we explicitly declare
|
|
a target namespace, and specify that both locally defined
|
|
elements and locally defined attributes must be
|
|
unqualified. The target namespace in <code><a href="#po1.xsd">po1.xsd</a></code> is <code>
|
|
http://www.example.com/PO1</code>, as indicated by the
|
|
value of the <code><a href="#attribute-targetNamespace">
|
|
targetNamespace</a></code> attribute.
|
|
</p><p id="ref50">Qualification of local elements and attributes can be
|
|
globally specified by a pair of attributes, <code><a href="#attribute-elementFormDefault">
|
|
elementFormDefault</a></code> and <code><a href="#attribute-attributeFormDefault">
|
|
attributeFormDefault</a></code>, on the <code><a href="#element-schema">schema</a></code> element, or can be
|
|
specified separately for each local declaration using the
|
|
<code><a href="#attribute-form">form</a></code> attribute.
|
|
All such attributes' values may each be set to <code>
|
|
unqualified</code> or <code>qualified</code>, to indicate
|
|
whether or not locally declared elements and attributes
|
|
must be unqualified.
|
|
</p><p>
|
|
In <code><a href="#po1.xsd">po1.xsd</a></code> we globally
|
|
specify the qualification of elements and attributes by
|
|
setting the values of both <code><a href="#attribute-elementFormDefault">
|
|
elementFormDefault</a></code> and <code><a href="#attribute-attributeFormDefault">
|
|
attributeFormDefault</a></code> to <code>
|
|
unqualified</code>. Strictly speaking, these settings are
|
|
unnecessary because the values are the defaults for the two
|
|
attributes; we make them here to highlight the contrast between
|
|
this case and other cases we describe later.
|
|
</p><div class="exampleOuter"><a id="po1.xsd" name="po1.xsd"/><div class="exampleHeader">Example</div><div class="exampleWrapper">Purchase Order Schema with Target Namespace, po1.xsd</div><div class="exampleInner"><pre>
|
|
<schema xmlns="http://www.w3.org/2001/XMLSchema"
|
|
xmlns:po="http://www.example.com/PO1"
|
|
targetNamespace="http://www.example.com/PO1"
|
|
elementFormDefault="unqualified"
|
|
attributeFormDefault="unqualified">
|
|
|
|
<element name="purchaseOrder" type="po:PurchaseOrderType"/>
|
|
<element name="comment" type="string"/>
|
|
|
|
<complexType name="PurchaseOrderType">
|
|
<sequence>
|
|
<element name="shipTo" type="po:USAddress"/>
|
|
<element name="billTo" type="po:USAddress"/>
|
|
<element ref="po:comment" minOccurs="0"/>
|
|
<!-- etc. -->
|
|
</sequence>
|
|
<!-- etc. -->
|
|
</complexType>
|
|
|
|
<complexType name="USAddress">
|
|
<sequence>
|
|
<element name="name" type="string"/>
|
|
<element name="street" type="string"/>
|
|
<!-- etc. -->
|
|
</sequence>
|
|
</complexType>
|
|
|
|
<!-- etc. -->
|
|
|
|
</schema>
|
|
</pre></div></div><p>
|
|
To see how the target namespace of this schema is
|
|
populated, we examine in turn each of the type
|
|
definitions and element declarations. Starting from the end
|
|
of the schema, we first define a type called <code>
|
|
USAddress</code> that consists of the elements <code>
|
|
name</code>, <code>street</code>, etc. One consequence of
|
|
this type definition is that the <code>USAddress</code>
|
|
type is included in the schema's target namespace. We next
|
|
define a type called <code>PurchaseOrderType</code> that
|
|
consists of the elements <code>shipTo</code>, <code>
|
|
billTo</code>, <code>comment</code>, etc. <code>
|
|
PurchaseOrderType</code> is also included in the schema's
|
|
target namespace. Notice that the type references in the
|
|
three element declarations are prefixed, i.e. <code>
|
|
po:USAddress</code>, <code>po:USAddress</code> and <code>
|
|
po:comment</code>, and the prefix is associated with the
|
|
namespace <code>http://www.example.com/PO1</code>. This is
|
|
the same namespace as the schema's target namespace, and so
|
|
a processor of this schema will know to look within this
|
|
schema for the definition of the type <code>
|
|
USAddress</code> and the declaration of the element <code>
|
|
comment</code>. It is also possible to refer to types in
|
|
another schema with a different target namespace, hence
|
|
enabling re-use of definitions and declarations between
|
|
schemas.
|
|
</p><p>
|
|
At the beginning of the schema <code><a href="#po1.xsd">
|
|
po1.xsd</a></code>, we declare the elements <code>
|
|
purchaseOrder</code> and <code> comment</code>. They are
|
|
included in the schema's target namespace. The <code>
|
|
purchaseOrder</code> element's type is prefixed, for the
|
|
same reason that <code>USAddress</code> is prefixed. In
|
|
contrast, the <code>comment</code> element's type, <code><a href="#string">string</a></code>, is not prefixed. The
|
|
<code> <a href="#po1.xsd">po1.xsd</a></code> schema
|
|
contains a default namespace declaration, and so unprefixed
|
|
types such as <code><a href="#string">string</a></code>
|
|
and unprefixed elements such as <code> <a href="#element-element">element</a></code> and <code><a href="#element-complexType">complexType</a></code> are
|
|
associated with the default namespace <code>
|
|
http://www.w3.org/2001/XMLSchema</code>. In fact, this
|
|
is the target namespace of XML Schema itself, and so a
|
|
processor of <code><a href="#po1.xsd">po1.xsd</a></code>
|
|
will know to look within the schema of XML Schema
|
|
-- otherwise known as the "schema for schemas" -- for the
|
|
definition of the type <code> <a href="#string">
|
|
string</a></code> and the declaration of the element called
|
|
<code><a href="#element-element">element</a></code>.
|
|
</p><p>
|
|
Let us now examine how the target namespace of the schema
|
|
affects a conforming instance document:
|
|
</p><div class="exampleOuter"><a id="po1.xml" name="po1.xml"/><div class="exampleHeader">Example</div><div class="exampleWrapper">A Purchase Order with Unqualified Locals, po1.xml</div><div class="exampleInner"><pre>
|
|
<?xml version="1.0"?>
|
|
<apo:purchaseOrder xmlns:apo="http://www.example.com/PO1"
|
|
orderDate="1999-10-20">
|
|
<shipTo country="US">
|
|
<name>Alice Smith</name>
|
|
<street>123 Maple Street</street>
|
|
<!-- etc. -->
|
|
</shipTo>
|
|
<billTo country="US">
|
|
<name>Robert Smith</name>
|
|
<street>8 Oak Avenue</street>
|
|
<!-- etc. -->
|
|
</billTo>
|
|
<apo:comment>Hurry, my lawn is going wild<!/apo:comment>
|
|
<!-- etc. -->
|
|
</apo:purchaseOrder>
|
|
</pre></div></div><p>
|
|
The instance document declares one namespace, <code>
|
|
http://www.example.com/PO1</code>, and associates it with
|
|
the prefix <code>apo:</code>. This prefix is used to
|
|
qualify two elements in the document, namely <code>
|
|
purchaseOrder</code> and <code>comment</code>. The
|
|
namespace is the same as the target namespace of the schema
|
|
in <code><a href="#po1.xsd">po1.xsd</a></code>, and so a
|
|
processor of the instance document will know to look in
|
|
that schema for the declarations of <code>
|
|
purchaseOrder</code> and <code>comment</code>. In fact,
|
|
target namespaces are so named because of the sense in
|
|
which there exists a target namespace for the elements
|
|
<code>purchaseOrder</code> and <code>comment</code>. Target
|
|
namespaces in the schema therefore control the validation
|
|
of corresponding namespaces in the instance.
|
|
</p><p>
|
|
The prefix <code>apo:</code> is applied to the global
|
|
elements <code>purchaseOrder</code> and <code>
|
|
comment</code> elements. Furthermore, <code><a href="#attribute-elementFormDefault">
|
|
elementFormDefault</a></code> and <code><a href="#attribute-attributeFormDefault">
|
|
attributeFormDefault</a></code> require that the prefix is
|
|
<em>not</em> applied to any of the locally declared
|
|
elements such as <code>shipTo</code>, <code>billTo</code>,
|
|
<code> name</code> and <code>street</code>, and it is <em>
|
|
not</em> applied to any of the attributes (which were all
|
|
declared locally). The <code>purchaseOrder</code> and
|
|
<code> comment</code> are global elements because they are
|
|
declared in the context of the schema as a whole rather
|
|
than within the context of a particular type. For example,
|
|
the declaration of <code>purchaseOrder</code> appears as a
|
|
child of the <code><a href="#element-schema">
|
|
schema</a></code> element in <code> <a href="#po1.xsd">
|
|
po1.xsd</a></code>, whereas the declaration of <code>
|
|
shipTo</code> appears as a child of the <code> <a href="#element-complexType">complexType</a></code> element that
|
|
defines <code>PurchaseOrderType</code>.
|
|
</p><p>
|
|
When local elements and attributes are not required to be
|
|
qualified, an instance author may require more or less
|
|
knowledge about the details of the schema to create schema
|
|
valid instance documents. More specifically, if the author
|
|
can be sure that only the root element (such as <code>
|
|
purchaseOrder</code>) is global, then it is a simple matter
|
|
to qualify only the root element. Alternatively, the author
|
|
may know that all the elements are declared globally, and
|
|
so all the elements in the instance document can be
|
|
prefixed, perhaps taking advantage of a default namespace
|
|
declaration. (We examine this approach in <a href="#GlobalvsLocal">Global vs. Local Declarations (§3.3)</a>.) On the other hand, if
|
|
there is no uniform pattern of global and local
|
|
declarations, the author will need detailed knowledge of
|
|
the schema to correctly prefix global elements and
|
|
attributes.
|
|
</p></div><div class="div2">
|
|
<h3><span class="nav"><a class="nav" href="#UnqualLocals"><img src="previous.jpg" alt="previous sub-section"/></a> <a class="nav" href="#GlobalvsLocal"><img src="next.jpg" alt="next sub-section"/></a></span><a id="QualLocals" name="QualLocals"/>3.2 Qualified Locals</h3><p>
|
|
Elements and attributes can be independently required to
|
|
be qualified, although we start by describing the
|
|
qualification of local elements. To specify that all
|
|
locally declared elements in a schema must be qualified, we
|
|
set the value of <code><a href="#attribute-elementFormDefault">
|
|
elementFormDefault</a></code> to <code>qualified</code>:
|
|
</p><div class="exampleOuter"><a id="ModificationsToPO1" name="ModificationsToPO1"/><div class="exampleHeader">Example</div><div class="exampleWrapper">Modifications to <a href="#po1.xsd">po1.xsd</a> for
|
|
Qualified Locals</div><div class="exampleInner"><pre>
|
|
<schema xmlns="http://www.w3.org/2001/XMLSchema"
|
|
xmlns:po="http://www.example.com/PO1"
|
|
targetNamespace="http://www.example.com/PO1"
|
|
elementFormDefault="qualified"
|
|
attributeFormDefault="unqualified">
|
|
|
|
<element name="purchaseOrder" type="po:PurchaseOrderType"/>
|
|
<element name="comment" type="string"/>
|
|
|
|
<complexType name="PurchaseOrderType">
|
|
<!-- etc. -->
|
|
</complexType>
|
|
|
|
<!-- etc. -->
|
|
|
|
</schema>
|
|
</pre></div></div><p>
|
|
And in this conforming instance document, we qualify all
|
|
the elements explicitly:
|
|
</p><div class="exampleOuter"><a id="POWithExplicitlyQualifiedLocals" name="POWithExplicitlyQualifiedLocals"/><div class="exampleHeader">Example</div><div class="exampleWrapper">A Purchase Order with Explicitly Qualified Locals</div><div class="exampleInner"><pre>
|
|
<?xml version="1.0"?>
|
|
<apo:purchaseOrder xmlns:apo="http://www.example.com/PO1"
|
|
orderDate="1999-10-20">
|
|
<apo:shipTo country="US">
|
|
<apo:name>Alice Smith</apo:name>
|
|
<apo:street>123 Maple Street</apo:street>
|
|
<!-- etc. -->
|
|
</apo:shipTo>
|
|
<apo:billTo country="US">
|
|
<apo:name>Robert Smith</apo:name>
|
|
<apo:street>8 Oak Avenue</apo:street>
|
|
<!-- etc. -->
|
|
</apo:billTo>
|
|
<apo:comment>Hurry, my lawn is going wild<!/apo:comment>
|
|
<!-- etc. -->
|
|
</apo:purchaseOrder>
|
|
</pre></div></div><p>
|
|
Alternatively, we can replace the explicit qualification
|
|
of every element with implicit qualification provided by a
|
|
default namespace, as shown here in <code><a href="#po2.xml">
|
|
po2.xml</a></code>:
|
|
</p><div class="exampleOuter"><a id="po2.xml" name="po2.xml"/><div class="exampleHeader">Example</div><div class="exampleWrapper">A Purchase Order with Default Qualified Locals, po2.xml</div><div class="exampleInner"><pre>
|
|
<?xml version="1.0"?>
|
|
<purchaseOrder xmlns="http://www.example.com/PO1"
|
|
orderDate="1999-10-20">
|
|
<shipTo country="US">
|
|
<name>Alice Smith</name>
|
|
<street>123 Maple Street</street>
|
|
<!-- etc. -->
|
|
</shipTo>
|
|
<billTo country="US">
|
|
<name>Robert Smith</name>
|
|
<street>8 Oak Avenue</street>
|
|
<!-- etc. -->
|
|
</billTo>
|
|
<comment>Hurry, my lawn is going wild<!/comment>
|
|
<!-- etc. -->
|
|
</purchaseOrder>
|
|
</pre></div></div><p>
|
|
In <code><a href="#po2.xml">po2.xml</a></code>, all the elements in the
|
|
instance belong to the same namespace, and the namespace
|
|
statement declares a default namespace that applies to all
|
|
the elements in the instance. Hence, it is unnecessary to
|
|
explicitly prefix any of the elements. As another
|
|
illustration of using qualified elements, the schemas in <a href="#quartelyReport">Advanced Concepts III: The Quarterly Report (§5)</a> all require qualified
|
|
elements.
|
|
</p><p>
|
|
Qualification of attributes is very similar to the
|
|
qualification of elements. Attributes that must be
|
|
qualified, either because they are declared globally or
|
|
because the <code><a href="#attribute-attributeFormDefault">
|
|
attributeFormDefault</a></code> attribute is set to <code>
|
|
qualified</code>, appear prefixed in instance documents.
|
|
One example of a qualified attribute is the <code><a href="#attribute-xsinil">xsi:nil</a></code> attribute that
|
|
was introduced in <a href="#Nils">Nil Values (§2.9)</a>. In
|
|
fact, attributes that are required to be qualified must be
|
|
explicitly prefixed because the <a href="http://www.w3.org/TR/1999/REC-xml-names-19990114/">Namespaces in XML</a>
|
|
specification does not provide a mechanism for defaulting
|
|
the namespaces of attributes. Attributes that are not
|
|
required to be qualified appear in instance documents
|
|
without prefixes, which is the typical case.
|
|
</p><p id="ref39">The qualification mechanism we have
|
|
described so far has controlled all local element and
|
|
attribute declarations within a particular target
|
|
namespace. It is also possible to control qualification on
|
|
a declaration by declaration basis using the <code><a href="#attribute-form">form</a></code> attribute. For example,
|
|
to require that the locally declared attribute <code>
|
|
publicKey</code> is qualified in instances, we declare it
|
|
in the following way:
|
|
</p><div class="exampleOuter"><a id="RequiringQualification" name="RequiringQualification"/><div class="exampleHeader">Example</div><div class="exampleWrapper">Requiring Qualification of Single Attribute</div><div class="exampleInner"><pre>
|
|
<schema xmlns="http://www.w3.org/2001/XMLSchema"
|
|
xmlns:po="http://www.example.com/PO1"
|
|
targetNamespace="http://www.example.com/PO1"
|
|
elementFormDefault="qualified"
|
|
attributeFormDefault="unqualified">
|
|
<!-- etc. -->
|
|
<element name="secure">
|
|
<complexType>
|
|
<sequence>
|
|
<!-- element declarations -->
|
|
</sequence>
|
|
<attribute name="publicKey" type="base64Binary" form="qualified"/>
|
|
</complexType>
|
|
</element>
|
|
</schema>
|
|
</pre></div></div><p>
|
|
Notice that the value of the <code><a href="#attribute-form">form</a></code> attribute overrides the
|
|
value of the <code><a href="#attribute-attributeFormDefault">
|
|
attributeFormDefault</a></code> attribute for the <code>
|
|
publicKey</code> attribute only. Also, the <code><a href="#attribute-form">form</a></code> attribute can be applied
|
|
to an element declaration in the same manner. An instance
|
|
document that conforms to the schema is:
|
|
</p><div class="exampleOuter"><a id="InstanceWithQualifiedAttribute" name="InstanceWithQualifiedAttribute"/><div class="exampleHeader">Example</div><div class="exampleWrapper">Instance with a Qualified Attribute</div><div class="exampleInner"><pre>
|
|
<?xml version="1.0"?>
|
|
<purchaseOrder xmlns="http://www.example.com/PO1"
|
|
xmlns:po="http://www.example.com/PO1"
|
|
orderDate="1999-10-20">
|
|
<!-- etc. -->
|
|
<secure po:publicKey="GpM7">
|
|
<!-- etc. -->
|
|
</secure>
|
|
</purchaseOrder>
|
|
</pre></div></div></div><div class="div2">
|
|
<h3><span class="nav"><a class="nav" href="#QualLocals"><img src="previous.jpg" alt="previous sub-section"/></a> <a class="nav" href="#UndeclaredTNS"><img src="next.jpg" alt="next sub-section"/></a></span><a id="GlobalvsLocal" name="GlobalvsLocal"/>3.3 Global vs. Local Declarations</h3><p>
|
|
Another authoring style, applicable when all element names are
|
|
unique within a namespace, is to create schemas in which
|
|
all elements are global. This is similar in effect to the
|
|
use of <!ELEMENT> in a DTD. In the example below, we
|
|
have modified the original <code><a href="#po1.xsd">po1.xsd</a></code>
|
|
such that all the elements are declared globally. Notice
|
|
that we have omitted the <code><a href="#attribute-elementFormDefault">
|
|
elementFormDefault</a></code> and <code><a href="#attribute-attributeFormDefault">
|
|
attributeFormDefault</a></code> attributes in this example
|
|
to emphasize that their values are irrelevant when there
|
|
are only global element and attribute declarations.
|
|
</p><div class="exampleOuter"><a id="ModifiedVersionOfPO1" name="ModifiedVersionOfPO1"/><div class="exampleHeader">Example</div><div class="exampleWrapper">Modified version of <a href="#po1.xsd">po1.xsd</a>
|
|
using only global element declarations</div><div class="exampleInner"><pre>
|
|
<schema xmlns="http://www.w3.org/2001/XMLSchema"
|
|
xmlns:po="http://www.example.com/PO1"
|
|
targetNamespace="http://www.example.com/PO1">
|
|
|
|
<element name="purchaseOrder" type="po:PurchaseOrderType"/>
|
|
|
|
<element name="shipTo" type="po:USAddress"/>
|
|
<element name="billTo" type="po:USAddress"/>
|
|
<element name="comment" type="string"/>
|
|
|
|
<element name="name" type="string"/>
|
|
<element name="street" type="string"/>
|
|
|
|
<complexType name="PurchaseOrderType">
|
|
<sequence>
|
|
<element ref="po:shipTo"/>
|
|
<element ref="po:billTo"/>
|
|
<element ref="po:comment" minOccurs="0"/>
|
|
<!-- etc. -->
|
|
</sequence>
|
|
</complexType>
|
|
|
|
<complexType name="USAddress">
|
|
<sequence>
|
|
<element ref="po:name"/>
|
|
<element ref="po:street"/>
|
|
<!-- etc. -->
|
|
</sequence>
|
|
</complexType>
|
|
|
|
<!-- etc. -->
|
|
|
|
</schema>
|
|
</pre></div></div><p>
|
|
This "global" version of <code><a href="#po1.xsd">po1.xsd</a></code>
|
|
will validate the instance document <code><a href="#po2.xml">
|
|
po2.xml</a></code> which, as we described previously, is also
|
|
schema valid against the "qualified" version of <code><a href="#po1.xsd">po1.xsd</a></code>. In other words, both schema
|
|
approaches can validate the same, namespace defaulted,
|
|
document. Thus, in one respect the two schema approaches
|
|
are similar, although in another important respect the two
|
|
schema approaches are very different. Specifically, when
|
|
all elements are declared globally, it is not possible to
|
|
take advantage of local names. For example, you can only
|
|
declare one global element called "title". However, you can
|
|
locally declare one element called "title" that has a
|
|
string type, and is a subelement of "book". Within the same
|
|
schema (target namespace) you can declare a second element
|
|
also called "title" that is an enumeration of the values
|
|
"Mr Mrs Ms".
|
|
</p></div><div class="div2">
|
|
<h3><span class="nav"><a class="nav" href="#GlobalvsLocal"><img src="previous.jpg" alt="previous sub-section"/></a> </span><a id="UndeclaredTNS" name="UndeclaredTNS"/>3.4 Undeclared Target Namespaces</h3><p>
|
|
In <a href="#PO">Basic Concepts: The Purchase Order (§2)</a> we explained the basics of
|
|
XML Schema using a schema that did not declare a target
|
|
namespace and an instance document that did not declare a
|
|
namespace. So the question naturally arises: What is the
|
|
target namespace in these examples and how is it
|
|
referenced?
|
|
</p><p>
|
|
In the purchase order schema, <code><a href="#po.xsd">
|
|
po.xsd</a></code>, we did not declare a target namespace
|
|
for the schema, nor did we declare a prefix (like <code>
|
|
po</code>: above) associated with the schema's target
|
|
namespace with which we could refer to types and elements
|
|
defined and declared within the schema. The consequence of
|
|
not declaring a target namespace in a schema is that the
|
|
definitions and declarations from that schema, such as
|
|
<code>USAddress</code> and <code>purchaseOrder</code>, are
|
|
referenced without namespace qualification. In other words
|
|
there is no explicit namespace prefix applied to the
|
|
references nor is there any implicit namespace applied to
|
|
the reference by default. So for example, the <code>
|
|
purchaseOrder</code> element is declared using the type
|
|
reference <code>PurchaseOrderType</code>. In contrast, all
|
|
the XML Schema elements and types used in <code><a href="#po.xsd">po.xsd</a></code> are explicitly qualified with
|
|
the prefix <code>xsd:</code> that is associated with the
|
|
XML Schema namespace.
|
|
</p><p>
|
|
In cases where a schema is designed without a target namespace, it is
|
|
strongly recommended that all XML Schema elements and types are <em>explicitly</em>
|
|
qualified with a prefix such as <code>xsd:</code> that is associated
|
|
with the XML Schema namespace (as in <code><a href="#po.xsd">po.xsd</a></code>). The rationale for this recommendation is
|
|
that if XML Schema elements and types are associated with the XML Schema
|
|
namespace by default, i.e. without prefixes, then references to XML
|
|
Schema types may not be distinguishable from references to user-defined
|
|
types.
|
|
</p><p>
|
|
Element declarations from a schema with no target
|
|
namespace validate unqualified elements in the instance
|
|
document. That is, they validate elements for which no
|
|
namespace qualification is provided by either an explicit
|
|
prefix or by default (<code>xmlns:</code>). So, to validate
|
|
a traditional XML 1.0 document which does not use
|
|
namespaces at all, you must provide a schema with no target
|
|
namespace. Of course, there are many XML 1.0 documents that
|
|
do not use namespaces, so there will be many schema
|
|
documents written without target namespaces; you must be
|
|
sure to give to your processor a schema document that
|
|
corresponds to the vocabulary you wish to validate.
|
|
</p></div></div><div class="div1">
|
|
<h2><a id="IPO" name="IPO"/>4 Advanced Concepts II: The International Purchase Order</h2><p>
|
|
The purchase order schema described in <a href="#PO">Basic Concepts: The Purchase Order (§2)</a>
|
|
was contained in a single document, and most
|
|
of the schema constructions-- such as element declarations
|
|
and type definitions-- were constructed from scratch. In
|
|
reality, schema authors will want to compose schemas from
|
|
constructions located in multiple documents, and to create new
|
|
types based on existing types. In this section, we examine
|
|
mechanisms that enable such compositions and creations.
|
|
</p><div class="div2">
|
|
<h3><span class="nav"> <a class="nav" href="#DerivExt"><img src="next.jpg" alt="next sub-section"/></a></span><a id="SchemaInMultDocs" name="SchemaInMultDocs"/>4.1 A Schema in Multiple Documents</h3><p>
|
|
As schemas become larger, it is often desirable to divide
|
|
their content among several schema documents for purposes
|
|
such as ease of maintenance, access control, and
|
|
readability. For these reasons, we have taken the schema
|
|
constructs concerning addresses out of <code><a href="#po.xsd">po.xsd</a></code>, and put them in a new file
|
|
called <code><a href="#address.xsd">address.xsd</a></code>.
|
|
The modified purchase order schema file is called <code> <a href="#ipo.xsd">ipo.xsd</a></code>:
|
|
</p><div class="exampleOuter"><a id="ipo.xsd" name="ipo.xsd"/><div class="exampleHeader">Example</div><div class="exampleWrapper">The International Purchase Order Schema, ipo.xsd</div><div class="exampleInner"><pre>
|
|
<schema targetNamespace="http://www.example.com/IPO"
|
|
xmlns="http://www.w3.org/2001/XMLSchema"
|
|
xmlns:ipo="http://www.example.com/IPO">
|
|
|
|
<annotation>
|
|
<documentation xml:lang="en">
|
|
International Purchase order schema for Example.com
|
|
Copyright 2000 Example.com. All rights reserved.
|
|
</documentation>
|
|
</annotation>
|
|
|
|
<!-- include address constructs -->
|
|
<include
|
|
schemaLocation="http://www.example.com/schemas/address.xsd"/>
|
|
|
|
<element name="purchaseOrder" type="ipo:PurchaseOrderType"/>
|
|
|
|
<element name="comment" type="string"/>
|
|
|
|
<complexType name="PurchaseOrderType">
|
|
<sequence>
|
|
<element name="shipTo" type="ipo:Address"/>
|
|
<element name="billTo" type="ipo:Address"/>
|
|
<element ref="ipo:comment" minOccurs="0"/>
|
|
<element name="items" type="ipo:Items"/>
|
|
</sequence>
|
|
<attribute name="orderDate" type="date"/>
|
|
</complexType>
|
|
|
|
<complexType name="Items">
|
|
<sequence>
|
|
<element name="item" minOccurs="0" maxOccurs="unbounded">
|
|
<complexType>
|
|
<sequence>
|
|
<element name="productName" type="string"/>
|
|
<element name="quantity">
|
|
<simpleType>
|
|
<restriction base="positiveInteger">
|
|
<maxExclusive value="100"/>
|
|
</restriction>
|
|
</simpleType>
|
|
</element>
|
|
<element name="USPrice" type="decimal"/>
|
|
<element ref="ipo:comment" minOccurs="0"/>
|
|
<element name="shipDate" type="date" minOccurs="0"/>
|
|
</sequence>
|
|
<attribute name="partNum" type="ipo:SKU" use="required"/>
|
|
</complexType>
|
|
</element>
|
|
</sequence>
|
|
</complexType>
|
|
|
|
<simpleType name="SKU">
|
|
<restriction base="string">
|
|
<pattern value="\d{3}-[A-Z]{2}"/>
|
|
</restriction>
|
|
</simpleType>
|
|
|
|
</schema>
|
|
</pre></div></div><p>
|
|
The file containing the address constructs is:
|
|
</p><div class="exampleOuter"><a id="address.xsd" name="address.xsd"/><div class="exampleHeader">Example</div><div class="exampleWrapper">Addresses for International Purchase Order schema, address.xsd</div><div class="exampleInner"><pre>
|
|
<schema targetNamespace="http://www.example.com/IPO"
|
|
xmlns="http://www.w3.org/2001/XMLSchema"
|
|
xmlns:ipo="http://www.example.com/IPO">
|
|
|
|
<annotation>
|
|
<documentation xml:lang="en">
|
|
Addresses for International Purchase order schema
|
|
Copyright 2000 Example.com. All rights reserved.
|
|
</documentation>
|
|
</annotation>
|
|
|
|
<complexType name="Address">
|
|
<sequence>
|
|
<element name="name" type="string"/>
|
|
<element name="street" type="string"/>
|
|
<element name="city" type="string"/>
|
|
</sequence>
|
|
</complexType>
|
|
|
|
<complexType name="USAddress">
|
|
<complexContent>
|
|
<extension base="ipo:Address">
|
|
<sequence>
|
|
<element name="state" type="ipo:USState"/>
|
|
<element name="zip" type="positiveInteger"/>
|
|
</sequence>
|
|
</extension>
|
|
</complexContent>
|
|
</complexType>
|
|
|
|
<complexType name="UKAddress">
|
|
<complexContent>
|
|
<extension base="ipo:Address">
|
|
<sequence>
|
|
<element name="postcode" type="ipo:UKPostcode"/>
|
|
</sequence>
|
|
<attribute name="exportCode" type="positiveInteger" fixed="1"/>
|
|
</extension>
|
|
</complexContent>
|
|
</complexType>
|
|
|
|
<!-- other Address derivations for more countries -->
|
|
|
|
<simpleType name="USState">
|
|
<restriction base="string">
|
|
<enumeration value="AK"/>
|
|
<enumeration value="AL"/>
|
|
<enumeration value="AR"/>
|
|
<!-- and so on ... -->
|
|
</restriction>
|
|
</simpleType>
|
|
|
|
<!-- simple type definition for UKPostcode -->
|
|
|
|
</schema>
|
|
</pre></div></div><p id="ref23">The various purchase order and
|
|
address constructions are now contained in two schema
|
|
files, <code><a href="#ipo.xsd">ipo.xsd</a></code> and
|
|
<code><a href="#address.xsd">address.xsd</a></code>. To
|
|
include these constructions as part of the international
|
|
purchase order schema, in other words to include them in
|
|
the international purchase order's namespace, <code><a href="#ipo.xsd">ipo.xsd</a></code> contains the <code> <a href="#element-include">include</a></code> element:
|
|
</p><div class="exampleOuter"><div class="exampleHeader">Example</div><div class="exampleInner"><pre>
|
|
<include schemaLocation="http://www.example.com/schemas/address.xsd"/>
|
|
</pre></div></div><p>
|
|
The effect of this <code><a href="#element-include">
|
|
include</a></code> element is to bring in the definitions
|
|
and declarations contained in <code><a href="#address.xsd">
|
|
address.xsd</a></code>, and make them available as part of
|
|
the international purchase order schema target namespace.
|
|
The one important caveat to using <code><a href="#element-include">include</a></code> is that the target
|
|
namespace of the included components must be the same as
|
|
the target namespace of the including schema, in this case
|
|
<code> http://www.example.com/IPO</code>. Bringing in
|
|
definitions and declarations using the <code><a href="#element-include"> include</a></code> mechanism
|
|
effectively adds these components to the existing target
|
|
namespace. In <a href="#Redefine">Redefining Types & Groups (§4.5)</a>, we
|
|
describe a similar mechanism that enables you to modify
|
|
certain components when they are brought in.
|
|
</p><p>
|
|
In our example, we have shown only one including document
|
|
and one included document. In practice it is possible to
|
|
include more than one document using multiple <code><a href="#element-include">include</a></code> elements, and
|
|
documents can include documents that themselves include
|
|
other documents. However, nesting documents in this manner
|
|
is legal only if all the
|
|
included parts of the schema are declared with the same
|
|
target namespace.
|
|
</p><p>
|
|
Instance documents that conform to schema whose
|
|
definitions span multiple schema documents need only
|
|
reference the 'topmost' document and the common namespace,
|
|
and it is the responsibility of the processor to gather
|
|
together all the definitions specified in the various
|
|
included documents. In our example above, the instance
|
|
document <code><a href="#ipo.xml">ipo.xml</a></code> (see
|
|
<a href="#UseDerivInInstDocs">Using Derived Types in Instance Documents (§4.3)</a>) references
|
|
only the common target namespace, <code>
|
|
http://www.example.com/IPO</code>, and (by implication) the one schema file
|
|
<code>http://www.example.com/schemas/ipo.xsd</code>. The
|
|
processor is responsible for obtaining the schema file
|
|
<code><a href="#address.xsd">address.xsd</a></code>.
|
|
</p><p>
|
|
In <a href="#import">Importing Types (§5.4)</a> we describe how
|
|
schemas can be used to validate content from more than one
|
|
namespace.
|
|
</p></div><div class="div2">
|
|
<h3><span class="nav"><a class="nav" href="#SchemaInMultDocs"><img src="previous.jpg" alt="previous sub-section"/></a> <a class="nav" href="#UseDerivInInstDocs"><img src="next.jpg" alt="next sub-section"/></a></span><a id="DerivExt" name="DerivExt"/>4.2 Deriving Types by Extension</h3><p>
|
|
To create our address constructs, we start by creating a
|
|
complex type called <code>Address</code> in the usual way
|
|
(see <code><a href="#address.xsd">address.xsd</a></code>).
|
|
The <code>Address</code> type contains the basic elements
|
|
of an address: a name, a street and a city. (Such a
|
|
definition will not work for all countries, but it
|
|
serves the purpose of our example.) From this starting
|
|
point we derive two new complex types that contain all the
|
|
elements of the original type plus additional elements that
|
|
are specific to addresses in the US and the UK. The
|
|
technique we use here to derive new (complex) address types
|
|
by extending an existing type is the same technique we used
|
|
in <a href="#complexTfromSimpleT">Complex Types from Simple Types (§2.5.1)</a>,
|
|
except that our base type here is a complex type whereas
|
|
our base type in the previous section was a simple type.
|
|
</p><p id="ref53">
|
|
We define the two new complex types, <code>
|
|
USAddress</code> and <code>UKAddress</code>, using the
|
|
<code><a href="#element-complexType">complexType</a></code>
|
|
element. In addition, we indicate that the content models
|
|
of the new types are complex, i.e. contain elements, by
|
|
using the <code><a href="#element-complexContent">
|
|
complexContent</a></code> element, and we indicate that we
|
|
are extending the base type <code>Address</code> by the
|
|
value of the <code><a href="#attribute-base">
|
|
base</a></code> attribute on the <code><a href="#element-extension">extension</a></code> element.
|
|
</p><p>
|
|
When a complex type is derived by extension, its effective
|
|
content model is the content model of the base type plus
|
|
the content model specified in the type derivation.
|
|
Furthermore, the two content models are treated as two
|
|
children of a sequential group. In the case of <code>
|
|
UKAddress</code>, the content model of <code>
|
|
UKAddress</code> is the content model of <code>
|
|
Address</code> plus the declarations for a <code>
|
|
postcode</code> element and an <code>exportCode</code>
|
|
attribute. This is like defining the <code>UKAddress</code>
|
|
from scratch as follows:
|
|
</p><div class="exampleOuter"><a id="EffectiveContentModel" name="EffectiveContentModel"/><div class="exampleHeader">Example</div><div class="exampleWrapper">Effective Content Model of UKAddress</div><div class="exampleInner"><pre>
|
|
<complexType name="UKAddress">
|
|
<sequence>
|
|
<!-- content model of Address -->
|
|
<element name="name" type="string"/>
|
|
<element name="street" type="string"/>
|
|
<element name="city" type="string"/>
|
|
|
|
<!-- appended element declaration -->
|
|
<element name="postcode" type="ipo:UKPostcode"/>
|
|
</sequence>
|
|
|
|
<!-- appended attribute declaration -->
|
|
<attribute name="exportCode" type="positiveInteger" fixed="1"/>
|
|
</complexType>
|
|
</pre></div></div></div><div class="div2">
|
|
<h3><span class="nav"><a class="nav" href="#DerivExt"><img src="previous.jpg" alt="previous sub-section"/></a> <a class="nav" href="#DerivByRestrict"><img src="next.jpg" alt="next sub-section"/></a></span><a id="UseDerivInInstDocs" name="UseDerivInInstDocs"/>4.3 Using Derived Types in Instance Documents</h3><p>
|
|
In our example scenario, purchase orders are generated in
|
|
response to customer orders which may involve shipping and
|
|
billing addresses in different countries. The international
|
|
purchase order, <code><a href="#ipo.xml">ipo.xml</a></code>
|
|
below, illustrates one such case where goods are shipped to
|
|
the UK and the bill is sent to a US address. Clearly it is
|
|
better if the schema for international purchase orders
|
|
does not have to spell out every possible combination of
|
|
international addresses for billing and shipping, and even
|
|
more so if we can add new complex types of international
|
|
address simply by creating new derivations of <code>
|
|
Address</code>.
|
|
</p><p id="ref24">XML Schema allows us to define the
|
|
<code>billTo</code> and <code>shipTo</code> elements as
|
|
<code>Address</code> types (see <code><a href="#ipo.xsd">
|
|
ipo.xsd</a></code>) but to use instances of international
|
|
addresses in place of instances of <code> Address</code>.
|
|
In other words, an instance document whose content conforms
|
|
to the <code>UKAddress</code> type will be valid if that
|
|
content appears within the document at a location where an
|
|
<code>Address</code> is expected (assuming the <code>
|
|
UKAddress</code> content itself is valid). To make this
|
|
feature of XML Schema work, and to identify exactly which
|
|
derived type is intended, the derived type must be
|
|
identified in the instance document. The type is identified
|
|
using the <code><a href="#attribute-xsitype">
|
|
xsi:type</a></code> attribute which is part of the XML
|
|
Schema instance namespace. In the example, <code><a href="#ipo.xml">ipo.xml</a></code>, use of the <code>
|
|
UKAddress</code> and <code>USAddress</code> derived types
|
|
is identified through the values assigned to the <code><a href="#attribute-xsitype">xsi:type</a></code> attributes.
|
|
</p><div class="exampleOuter"><a id="ipo.xml" name="ipo.xml"/><div class="exampleHeader">Example</div><div class="exampleWrapper">An International Purchase order, ipo.xml</div><div class="exampleInner"><pre>
|
|
<?xml version="1.0"?>
|
|
<ipo:purchaseOrder
|
|
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
|
|
xmlns:ipo="http://www.example.com/IPO"
|
|
orderDate="1999-12-01">
|
|
|
|
<shipTo exportCode="1" xsi:type="ipo:UKAddress">
|
|
<name>Helen Zoe</name>
|
|
<street>47 Eden Street</street>
|
|
<city>Cambridge</city>
|
|
<postcode>CB1 1JR</postcode>
|
|
</shipTo>
|
|
|
|
<billTo xsi:type="ipo:USAddress">
|
|
<name>Robert Smith</name>
|
|
<street>8 Oak Avenue</street>
|
|
<city>Old Town</city>
|
|
<state>PA</state>
|
|
<zip>95819</zip>
|
|
</billTo>
|
|
|
|
<items>
|
|
<item partNum="833-AA">
|
|
<productName>Lapis necklace</productName>
|
|
<quantity>1</quantity>
|
|
<USPrice>99.95</USPrice>
|
|
<ipo:comment>Want this for the holidays<!/ipo:comment>
|
|
<shipDate>1999-12-05</shipDate>
|
|
</item>
|
|
</items>
|
|
</ipo:purchaseOrder>
|
|
</pre></div></div><p>
|
|
In <a href="#restrictingTypeDerivs">Controlling the Creation & Use of Derived Types (§4.8)</a> we describe
|
|
how to prevent derived types from being used in this
|
|
sort of substitution.
|
|
</p></div><div class="div2">
|
|
<h3><span class="nav"><a class="nav" href="#UseDerivInInstDocs"><img src="previous.jpg" alt="previous sub-section"/></a> <a class="nav" href="#Redefine"><img src="next.jpg" alt="next sub-section"/></a></span><a id="DerivByRestrict" name="DerivByRestrict"/>4.4 Deriving Complex Types by Restriction</h3><p>
|
|
In addition to deriving new complex types by extending
|
|
content models, it is possible to derive new types by
|
|
restricting the content models of existing types.
|
|
Restriction of complex types is conceptually the same as
|
|
restriction of simple types, except that the restriction of
|
|
complex types involves a type's declarations rather than
|
|
the acceptable range of a simple type's values. A complex
|
|
type derived by restriction is very similar to its base
|
|
type, except that its declarations are more limited than
|
|
the corresponding declarations in the base type. In fact,
|
|
the values represented by the new type are a subset of the
|
|
values represented by the base type (as is the case
|
|
with restriction of simple types). In other words, an
|
|
application prepared for the values of the base type would
|
|
not be surprised by the values of the restricted type.
|
|
</p><p id="ref54">
|
|
For example, suppose we want to update our definition of a purchase
|
|
order so that it must contain a <code>comment</code>;
|
|
the schema shown in <code> <a href="#ipo.xsd">ipo.xsd</a></code> allows a <code>purchaseOrder</code>
|
|
element to appear without any child
|
|
<code>comment</code>
|
|
elements. To create our new
|
|
<code>RestrictedPurchaseOrderType</code>
|
|
type, we define the new type in the usual way, indicate
|
|
that it is derived by restriction from the base type
|
|
<code>PurchaseOrderType</code>
|
|
, and provide a new (more restrictive) value for
|
|
the minimum number of
|
|
<code>comment</code> element
|
|
occurrences. Notice that types derived by restriction must
|
|
repeat all the particle components
|
|
(element declarations, model groups, and wildcards) of the base type definition that
|
|
are to be included in the derived type. However,
|
|
attribute declarations do not need to be repeated in the derived type definition; in this example, <code>RestrictedPurchaseOrderType</code> will inherit the
|
|
<code>orderDate</code> attribute declaration from <code>PurchaseOrderType</code>.
|
|
</p><div class="exampleOuter"><a id="DerivingRestrictedPOType" name="DerivingRestrictedPOType"/><div class="exampleHeader">Example</div><div class="exampleWrapper">
|
|
Deriving RestrictedPurchaseOrderType by Restriction from PurchaseOrderType</div><div class="exampleInner"><pre>
|
|
|
|
<complexType name="RestrictedPurchaseOrderType">
|
|
<complexContent>
|
|
<restriction base="ipo:PurchaseOrderType">
|
|
<sequence>
|
|
<element name="shipTo" type="ipo:Address"/>
|
|
<element name="billTo" type="ipo:Address"/>
|
|
<element ref="ipo:comment" minOccurs="1"/>
|
|
<element name="items" type="ipo:Items"/>
|
|
</sequence>
|
|
</restriction>
|
|
</complexContent>
|
|
</complexType>
|
|
</pre></div></div><p>
|
|
This change narrows the
|
|
allowable number of
|
|
<code>comment</code> elements from a minimum of 0 to a
|
|
minimum of 1. Note that all
|
|
<code>RestrictedPurchaseOrderType</code>
|
|
type elements will also be acceptable as
|
|
<code>PurchaseOrderType</code>
|
|
type elements.
|
|
</p><p>
|
|
To further illustrate restriction, <a href="#restrictsTable">Table 3</a> shows several examples of
|
|
how element and attribute declarations within type
|
|
definitions may be restricted (the table shows element
|
|
syntax although the first three examples are equally valid
|
|
attribute restrictions).
|
|
</p><a id="restrictsTable" name="restrictsTable"/><table summary="examples of restriction" width="100%" border="2"><tbody><tr><th colspan="3" align="left">Table 3. Restriction Examples</th></tr><tr><th>Base</th><th>Restriction(s)</th><th>Notes</th></tr><tr><td/><td align="center">default="1"</td><td>setting a default value where none was previously
|
|
given</td></tr><tr><td/><td align="center">fixed="100"</td><td>setting a fixed value where none was previously given</td></tr><tr><td/><td align="center">type="<a href="#string">string</a>"</td><td>specifying a type where none was previously given</td></tr><tr><th>(<a href="#attribute-minOccurs">minOccurs</a>, <a href="#attribute-maxOccurs">maxOccurs</a>)</th><th>(<a href="#attribute-minOccurs">minOccurs</a>, <a href="#attribute-maxOccurs">maxOccurs</a>)</th><th/></tr><tr><td align="center">(0, 1)</td><td align="center">(0, 0)</td><td>exclusion of an optional component; this may also be
|
|
accomplished by omitting the component's declaration
|
|
from the restricted type definition</td></tr><tr><td align="center">(0, 1)</td><td align="center">(1, 1)</td><td>making an optional component required</td></tr><tr><td align="center">(0, unbounded)</td><td align="center">
|
|
<table border="0"><tbody><tr><td align="center">(0, 0)</td></tr><tr><td align="center">(0, 37)</td></tr><tr><td align="center">(1, 37)</td></tr></tbody></table>
|
|
</td><td/></tr><tr><td align="center">(1, 9)</td><td align="center">
|
|
<table border="0"><tbody><tr><td align="center">(1, 8)</td></tr><tr><td align="center">(2, 9)</td></tr><tr><td align="center">(4, 7)</td></tr><tr><td align="center">(3, 3)</td></tr></tbody></table>
|
|
</td><td/></tr><tr><td align="center">(1, unbounded)</td><td align="center">
|
|
<table border="0"><tbody><tr><td align="center">(1, 12)</td></tr><tr><td align="center">(3, unbounded)</td></tr><tr><td align="center">(6, 6)</td></tr></tbody></table>
|
|
</td><td/></tr><tr><td align="center">(1, 1)</td><td align="center">(1, 1)</td><td>cannot further restrict <a href="#attribute-minOccurs">minOccurs</a> or <a href="#attribute-maxOccurs">maxOccurs</a></td></tr></tbody></table></div><div class="div2">
|
|
<h3><span class="nav"><a class="nav" href="#DerivByRestrict"><img src="previous.jpg" alt="previous sub-section"/></a> <a class="nav" href="#SubsGroups"><img src="next.jpg" alt="next sub-section"/></a></span><a id="Redefine" name="Redefine"/>4.5 Redefining Types & Groups</h3><p id="ref52">
|
|
In <a href="#SchemaInMultDocs">A Schema in Multiple Documents (§4.1)</a> we
|
|
described how to include definitions and declarations
|
|
obtained from external schema files having the same target
|
|
namespace. The <code><a href="#element-include">
|
|
include</a></code> mechanism enables you to use externally
|
|
created schema components "as-is", that is, without any
|
|
modification. We have just described how to derive new
|
|
types by extension and by restriction, and the <code><a href="#element-redefine">redefine</a></code> mechanism we
|
|
describe here enables you to redefine simple and
|
|
complex types, groups, and attribute groups that are
|
|
obtained from external schema files. Like the <code><a href="#element-include">include</a></code> mechanism,
|
|
<code><a href="#element-redefine">redefine</a></code>
|
|
requires the external components to be in the same target
|
|
namespace as the redefining schema, although external
|
|
components from schemas that have no namespace can also be
|
|
redefined. In the latter cases, the redefined components
|
|
become part of the redefining schema's target namespace.
|
|
</p><p>
|
|
To illustrate the <code><a href="#element-redefine">
|
|
redefine</a></code> mechanism, we use it instead of
|
|
the <code><a href="#element-include">include</a></code>
|
|
mechanism in the International Purchase Order schema,
|
|
<code><a href="#ipo.xsd">ipo.xsd</a></code>, and we
|
|
use it to modify the definition of the complex type <code>
|
|
Address</code> contained in <code><a href="#address.xsd">
|
|
address.xsd</a></code>:
|
|
</p><div class="exampleOuter"><a id="UsingRedefineInInternational" name="UsingRedefineInInternational"/><div class="exampleHeader">Example</div><div class="exampleWrapper">Using redefine in the International Purchase Order</div><div class="exampleInner"><pre>
|
|
<schema targetNamespace="http://www.example.com/IPO"
|
|
xmlns="http://www.w3.org/2001/XMLSchema"
|
|
xmlns:ipo="http://www.example.com/IPO">
|
|
|
|
<!-- bring in address constructs -->
|
|
<redefine
|
|
schemaLocation="http://www.example.com/schemas/address.xsd">
|
|
|
|
<!-- redefinition of Address -->
|
|
<complexType name="Address">
|
|
<complexContent>
|
|
<extension base="ipo:Address">
|
|
<sequence>
|
|
<element name="country" type="string"/>
|
|
</sequence>
|
|
</extension>
|
|
</complexContent>
|
|
</complexType>
|
|
|
|
</redefine>
|
|
|
|
<!-- etc. -->
|
|
|
|
</schema>
|
|
</pre></div></div><p>
|
|
The <code><a href="#element-redefine">redefine</a></code>
|
|
element acts very much like the <code><a href="#element-include">include</a></code> element as it includes
|
|
all the declarations and definitions from the <code><a href="#address.xsd">address.xsd</a></code> file. The
|
|
complex type definition of <code>Address</code> uses the
|
|
familiar extension syntax to add a <code>country</code>
|
|
element to the definition of <code>Address</code>. However,
|
|
note that the base type is also <code>Address</code>.
|
|
Outside of the <code><a href="#element-redefine">
|
|
redefine</a></code> element, any such attempt to define a
|
|
complex type with the same name (and in the same namespace)
|
|
as the base from which it is being derived would cause an
|
|
error. But in this case, there is no error, and the
|
|
extended definition of <code>Address</code> becomes the
|
|
only definition of <code>Address</code>.
|
|
</p><p>
|
|
Now that <code>Address</code> has been redefined, the
|
|
extension applies to all schema components that make use of
|
|
<code>Address</code>. For example, <code><a href="#address.xsd">
|
|
address.xsd</a></code> contains definitions of international
|
|
address types that are derived from <code>Address</code>.
|
|
These derivations reflect the redefined <code>
|
|
Address</code> type, as shown in the following snippet:
|
|
</p><div class="exampleOuter"><a id="SnippetOfRedefinedAddress" name="SnippetOfRedefinedAddress"/><div class="exampleHeader">Example</div><div class="exampleWrapper">Snippet of <a href="#ipo.xml">ipo.xml</a> using Redefined Address</div><div class="exampleInner"><pre>
|
|
....
|
|
<shipTo exportCode="1" xsi:type="ipo:UKAddress">
|
|
<name>Helen Zoe</name>
|
|
<street>47 Eden Street</street>
|
|
<city>Cambridge</city>
|
|
<!-- country was added to Address which is base type of UKAddress -->
|
|
<country>United Kingdom</country>
|
|
<!-- postcode was added as part of UKAddress -->
|
|
<postcode>CB1 1JR</postcode>
|
|
</shipTo>
|
|
....
|
|
</pre></div></div><p>
|
|
Our example has been carefully constructed so that the
|
|
redefined <code>Address</code> type does not conflict in
|
|
any way with the types that are derived from the original
|
|
<code>Address</code> definition. But note that it would be
|
|
very easy to create a conflict. For example, if the
|
|
international address type derivations had extended <code>
|
|
Address</code> by adding a <code>country</code> element,
|
|
then the redefinition of <code>Address</code> would be
|
|
adding an element of the same name to the content model of
|
|
<code>Address</code>. It is illegal to have two elements of
|
|
the same name (and in the same target namespace) but
|
|
different types in a content model, and so the attempt to
|
|
redefine <code>Address</code> would cause an error. In
|
|
general, <code><a href="#element-redefine">
|
|
redefine</a></code> does not protect you from such errors,
|
|
and it should be used cautiously.
|
|
</p></div><div class="div2">
|
|
<h3><span class="nav"><a class="nav" href="#Redefine"><img src="previous.jpg" alt="previous sub-section"/></a> <a class="nav" href="#abstract"><img src="next.jpg" alt="next sub-section"/></a></span><a id="SubsGroups" name="SubsGroups"/>4.6 Substitution Groups</h3><p id="ref25">XML Schema provides a mechanism,
|
|
called substitution groups, that allows elements to be
|
|
substituted for other elements. More specifically, elements
|
|
can be assigned to a special group of elements that are
|
|
said to be substitutable for a particular named element
|
|
called the head element. (Note that the head element
|
|
as well as the substitutable
|
|
elementsmust
|
|
be declared as global
|
|
elements.) To illustrate, we
|
|
declare two elements called <code> customerComment</code>
|
|
and <code> shipComment</code> and assign them to a
|
|
substitution group whose head element is <code>
|
|
comment</code>, and so <code> customerComment</code> and
|
|
<code>shipComment</code> can be used anyplace that we are
|
|
able to use <code> comment</code>. Elements in a
|
|
substitution group must have the same type as the head
|
|
element, or they can have a type that has been derived from
|
|
the head element's type. To declare these two new elements,
|
|
and to make them substitutable for the <code>
|
|
comment</code> element, we use the following syntax:
|
|
</p><div class="exampleOuter"><a id="DeclaringElementsSubstitutable" name="DeclaringElementsSubstitutable"/><div class="exampleHeader">Example</div><div class="exampleWrapper">Declaring Elements Substitutable for comment</div><div class="exampleInner"><pre>
|
|
<element name="shipComment" type="string"
|
|
substitutionGroup="ipo:comment"/>
|
|
<element name="customerComment" type="string"
|
|
substitutionGroup="ipo:comment"/>
|
|
</pre></div></div><p>
|
|
When these declarations are added to the international
|
|
purchase order schema, <code>shipComment</code> and
|
|
<code>customerComment</code> can be substituted for
|
|
<code>comment</code> in the instance document, for example:
|
|
</p><div class="exampleOuter"><a id="SnippetOfSubstitutedElements" name="SnippetOfSubstitutedElements"/><div class="exampleHeader">Example</div><div class="exampleWrapper">Snippet of <a href="#ipo.xml">ipo.xml</a> with
|
|
Substituted Elements</div><div class="exampleInner"><pre>
|
|
....
|
|
<items>
|
|
<item partNum="833-AA">
|
|
<productName>Lapis necklace</productName>
|
|
<quantity>1</quantity>
|
|
<USPrice>99.95</USPrice>
|
|
<ipo:shipComment>
|
|
Use gold wrap if possible
|
|
</ipo:shipComment>
|
|
<ipo:customerComment>
|
|
Want this for the holidays!
|
|
</ipo:customerComment>
|
|
<shipDate>1999-12-05</shipDate>
|
|
</item>
|
|
</items>
|
|
....
|
|
</pre></div></div><p>
|
|
Note that when an instance document contains element
|
|
substitutions whose types are derived from those of their
|
|
head elements, it is <em>not</em> necessary to identify the
|
|
derived types using the <code><a href="#attribute-xsitype">xsi:type</a></code> construction that
|
|
we described in <a href="#UseDerivInInstDocs">Using Derived Types in Instance Documents (§4.3)</a>.
|
|
</p><p>
|
|
The existence of a substitution group does not require any
|
|
of the elements in that class to be used, nor does it
|
|
preclude use of the head element. It simply provides a
|
|
mechanism for allowing elements to be used interchangeably.
|
|
</p></div><div class="div2">
|
|
<h3><span class="nav"><a class="nav" href="#SubsGroups"><img src="previous.jpg" alt="previous sub-section"/></a> <a class="nav" href="#restrictingTypeDerivs"><img src="next.jpg" alt="next sub-section"/></a></span><a id="abstract" name="abstract"/>4.7 Abstract Elements and Types</h3><p id="ref26">XML Schema provides a mechanism to
|
|
force substitution for a particular element or type. When
|
|
an element or type is declared to be "abstract", it cannot
|
|
be used in an instance document. When an element is
|
|
declared to be abstract, a member of that element's
|
|
substitution group must appear in the instance document.
|
|
When an element's corresponding type definition is declared
|
|
as abstract, all instances of that element must use <code>
|
|
<a href="#attribute-xsitype">xsi:type</a></code> to
|
|
indicate a derived type that is not abstract.
|
|
</p><p>
|
|
In the substitution group example we described in <a href="#SubsGroups">Substitution Groups (§4.6)</a>, it would be useful to
|
|
specifically disallow use of the <code>comment</code>
|
|
element so that instances must make use of the <code>
|
|
customerComment</code> and <code> shipComment</code>
|
|
elements. To declare the <code>comment</code> element
|
|
abstract, we modify its original declaration in the
|
|
international purchase order schema, <code><a href="#ipo.xsd">ipo.xsd</a></code>, as follows:
|
|
</p><div class="exampleOuter"><div class="exampleHeader">Example</div><div class="exampleInner"><pre>
|
|
<element name="comment" type="string" abstract="true"/>
|
|
</pre></div></div><p>
|
|
With <code>comment</code> declared as abstract, instances
|
|
of international purchase orders are now only valid if they
|
|
contain <code>customerComment</code> and <code>
|
|
shipComment</code> elements.
|
|
</p><p>
|
|
Declaring an element as abstract requires the use of a
|
|
substitution group. Declaring a type as abstract simply
|
|
requires the use of a type derived from it (and identified
|
|
by the <code><a href="#attribute-xsitype">
|
|
xsi:type</a></code> attribute) in the instance document.
|
|
Consider the following schema definition:
|
|
</p><div class="exampleOuter"><a id="SchemaForVehicles" name="SchemaForVehicles"/><div class="exampleHeader">Example</div><div class="exampleWrapper">Schema for Vehicles</div><div class="exampleInner"><pre>
|
|
<schema xmlns="http://www.w3.org/2001/XMLSchema"
|
|
targetNamespace="http://cars.example.com/schema"
|
|
xmlns:target="http://cars.example.com/schema">
|
|
|
|
<complexType name="Vehicle" abstract="true"/>
|
|
|
|
<complexType name="Car">
|
|
<complexContent>
|
|
<extension base="target:Vehicle"/>
|
|
</complexContent>
|
|
</complexType>
|
|
|
|
<complexType name="Plane">
|
|
<complexContent>
|
|
<extension base="target:Vehicle"/>
|
|
</complexContent>
|
|
</complexType>
|
|
|
|
<element name="transport" type="target:Vehicle"/>
|
|
</schema>
|
|
</pre></div></div><p>
|
|
The <code>transport</code> element is not abstract,
|
|
therefore it can appear in instance documents. However,
|
|
because its type definition is abstract, it may never
|
|
appear in an instance document without an <code> <a href="#attribute-xsitype">xsi:type</a></code> attribute that
|
|
refers to a derived type. That means the following is not
|
|
schema-valid:
|
|
</p><div class="exampleOuter"><div class="exampleHeader">Example</div><div class="exampleInner"><pre>
|
|
<transport xmlns="http://cars.example.com/schema"/>
|
|
</pre></div></div><p>
|
|
because the <code>transport</code> element's type is
|
|
abstract. However, the following is schema-valid:
|
|
</p><div class="exampleOuter"><div class="exampleHeader">Example</div><div class="exampleInner"><pre>
|
|
<transport xmlns="http://cars.example.com/schema"
|
|
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
|
|
xsi:type="Car"/>
|
|
</pre></div></div><p>
|
|
because it uses a non-abstract type that is substitutable
|
|
for <code>Vehicle</code>.
|
|
</p></div><div class="div2">
|
|
<h3><span class="nav"><a class="nav" href="#abstract"><img src="previous.jpg" alt="previous sub-section"/></a> </span><a id="restrictingTypeDerivs" name="restrictingTypeDerivs"/>4.8 Controlling the Creation & Use of Derived Types</h3><p id="ref27">So far, we have been able to derive
|
|
new types and use them in instance documents without any
|
|
restraints. In reality, schema authors will sometimes want
|
|
to control derivations of particular types, and the use of
|
|
derived types in instances.
|
|
</p><p>
|
|
XML Schema provides a couple of mechanisms that control
|
|
the derivation of types. One of these mechanisms allows the
|
|
schema author to specify that for a particular complex
|
|
type, new types may not be derived from it, either (a) by
|
|
restriction, (b) by extension, or (c) at all. To
|
|
illustrate, suppose we want to prevent any derivation of
|
|
the <code> Address</code> type by restriction because we
|
|
intend for it only to be used as the base for extended
|
|
types such as <code>USAddress</code> and <code>
|
|
UKAddress</code>. To prevent any such derivations, we
|
|
slightly modify the original definition of <code>
|
|
Address</code> as follows:
|
|
</p><div class="exampleOuter"><a id="PreventingDerivationsByRestriction" name="PreventingDerivationsByRestriction"/><div class="exampleHeader">Example</div><div class="exampleWrapper">Preventing Derivations by Restriction of Address</div><div class="exampleInner"><pre>
|
|
<complexType name="Address" final="restriction">
|
|
<sequence>
|
|
<element name="name" type="string"/>
|
|
<element name="street" type="string"/>
|
|
<element name="city" type="string"/>
|
|
</sequence>
|
|
</complexType>
|
|
</pre></div></div><p id="ref43">The <code>restriction</code> value of
|
|
the <code><a href="#attribute-final">final</a></code>
|
|
attribute prevents derivations by restriction. Preventing
|
|
derivations at all, or by extension, are indicated by the
|
|
values <code>#all</code> and <code> extension</code>
|
|
respectively. Moreover, there exists an optional <code><a href="#attribute-finalDefault">finalDefault</a></code> attribute
|
|
on the <code><a href="#element-schema">schema</a></code>
|
|
element whose value can be one of the values allowed for
|
|
the <code><a href="#attribute-final">final</a></code>
|
|
attribute. The effect of specifying the <code><a href="#attribute-finalDefault">finalDefault</a></code> attribute
|
|
is equivalent to specifying a <code><a href="#attribute-final">final</a></code> attribute on every type
|
|
definition and element declaration in the schema.
|
|
</p><p id="ref44">Another type-derivation mechanism
|
|
controls which facets can be applied in the derivation of a
|
|
new simple type. When a simple type is defined, the <code>
|
|
<a href="#attribute-facet-fixed">fixed</a></code> attribute
|
|
may be applied to any of its facets to prevent a derivation
|
|
of that type from modifying the value of the fixed facets.
|
|
For example, we can define a <code>Postcode</code> simple
|
|
type as:
|
|
</p><div class="exampleOuter"><a id="PreventingChangestoFacets" name="PreventingChangestoFacets"/><div class="exampleHeader">Example</div><div class="exampleWrapper">Preventing Changes to Simple Type Facets</div><div class="exampleInner"><pre>
|
|
<simpleType name="Postcode">
|
|
<restriction base="string">
|
|
<length value="7" fixed="true"/>
|
|
</restriction>
|
|
</simpleType>
|
|
</pre></div></div><p>
|
|
Once this simple type has been defined, we can derive a
|
|
new postal code type in which we apply a facet not fixed in
|
|
the base definition, for example:
|
|
</p><div class="exampleOuter"><a id="LegalDerivationFromPostcode" name="LegalDerivationFromPostcode"/><div class="exampleHeader">Example</div><div class="exampleWrapper">Legal Derivation from Postcode</div><div class="exampleInner"><pre>
|
|
<simpleType name="UKPostcode">
|
|
<restriction base="ipo:Postcode">
|
|
<pattern value="[A-Z]{2}\d\s\d[A-Z]{2}"/>
|
|
</restriction>
|
|
</simpleType>
|
|
</pre></div></div><p>
|
|
However, we cannot derive a new postal code in which we
|
|
re-apply any facet that was fixed in the base definition:
|
|
</p><div class="exampleOuter"><a id="IllegalDerivationFromPostcode" name="IllegalDerivationFromPostcode"/><div class="exampleHeader">Example</div><div class="exampleWrapper">Illegal Derivation from Postcode</div><div class="exampleInner"><pre>
|
|
<simpleType name="UKPostcode">
|
|
<restriction base="ipo:Postcode">
|
|
<pattern value="[A-Z]{2}\d\d[A-Z]{2}"/>
|
|
<!-- illegal attempt to modify facet fixed in base type -->
|
|
<length value="6" fixed="true"/>
|
|
</restriction>
|
|
</simpleType>
|
|
</pre></div></div><p id="ref28">In addition to the mechanisms that
|
|
control type derivations, XML Schema provides a mechanism
|
|
that controls which derivations and substitution groups may
|
|
be used in instance documents. In <a href="#UseDerivInInstDocs">Using Derived Types in Instance Documents (§4.3)</a>, we described how the
|
|
derived types, <code> USAddress</code> and <code>
|
|
UKAddress</code>, could be used by the <code>shipTo</code>
|
|
and <code>billTo</code> elements in instance documents.
|
|
These derived types can replace the content model provided
|
|
by the <code> Address</code> type because they are derived
|
|
from the <code>Address</code> type. However, replacement by
|
|
derived types can be controlled using the <code><a href="#attribute-block">block</a></code> attribute in a type
|
|
definition. For example, if we want to block any
|
|
derivation-by-restriction from being used in place of
|
|
<code>Address</code> (perhaps for the same reason we
|
|
defined <code>Address</code> with <code> <a href="#attribute-final">final</a>="restriction"</code>), we can
|
|
modify the original definition of <code>Address</code> as
|
|
follows:
|
|
</p><div class="exampleOuter"><a id="PreventingDerivationsInInstance" name="PreventingDerivationsInInstance"/><div class="exampleHeader">Example</div><div class="exampleWrapper">Preventing Derivations by Restriction of Address in
|
|
the Instance</div><div class="exampleInner"><pre>
|
|
<complexType name="Address" block="restriction">
|
|
<sequence>
|
|
<element name="name" type="string"/>
|
|
<element name="street" type="string"/>
|
|
<element name="city" type="string"/>
|
|
</sequence>
|
|
</complexType>
|
|
</pre></div></div><p id="ref42">The <code>restriction</code> value on
|
|
the <code> <a href="#attribute-block">block</a></code>
|
|
attribute prevents derivations-by-restriction from
|
|
replacing <code>Address</code> in an instance. However, it
|
|
would not prevent <code>UKAddress</code> and <code>
|
|
USAddress</code> from replacing <code>Address</code>
|
|
because they were derived by extension. Preventing
|
|
replacement by derivations at all, or by
|
|
derivations-by-extension, are indicated by the values
|
|
<code>#all</code> and <code>extension</code> respectively.
|
|
As with <code><a href="#attribute-final">final</a></code>,
|
|
there exists an optional <code><a href="#attribute-blockDefault">blockDefault</a></code> attribute
|
|
on the <code><a href="#element-schema">schema</a></code>
|
|
element whose value can be one of the values allowed for
|
|
the <code><a href="#attribute-block">block</a></code>
|
|
attribute. The effect of specifying the <code><a href="#attribute-blockDefault">blockDefault</a></code> attribute
|
|
is equivalent to specifying a <code><a href="#attribute-block">block</a></code> attribute on every type
|
|
definition and element declaration in the schema.
|
|
</p></div></div><div class="div1">
|
|
<h2><a id="quartelyReport" name="quartelyReport"/>5 Advanced Concepts III: The Quarterly Report</h2><p>
|
|
The home-products ordering and billing application can
|
|
generate ad-hoc reports that summarize how many of which
|
|
types of products have been billed on a per region basis.
|
|
An example of such a report, one that covers the fourth
|
|
quarter of 1999, is shown in <code><a href="#Q99.xml">
|
|
4Q99.xml</a></code>.
|
|
</p><p>
|
|
Notice that in this section we use qualified elements in
|
|
the schema, and default namespaces where possible in the
|
|
instances.
|
|
</p><div class="exampleOuter"><a id="Q99.xml" name="Q99.xml"/><div class="exampleHeader">Example</div><div class="exampleWrapper">Quarterly Report, 4Q99.xml</div><div class="exampleInner"><pre>
|
|
<purchaseReport
|
|
xmlns="http://www.example.com/Report"
|
|
period="P3M" periodEnding="1999-12-31">
|
|
|
|
<regions>
|
|
<zip code="95819">
|
|
<part number="872-AA" quantity="1"/>
|
|
<part number="926-AA" quantity="1"/>
|
|
<part number="833-AA" quantity="1"/>
|
|
<part number="455-BX" quantity="1"/>
|
|
</zip>
|
|
<zip code="63143">
|
|
<part number="455-BX" quantity="4"/>
|
|
</zip>
|
|
</regions>
|
|
|
|
<parts>
|
|
<part number="872-AA">Lawnmower</part>
|
|
<part number="926-AA">Baby Monitor</part>
|
|
<part number="833-AA">Lapis Necklace</part>
|
|
<part number="455-BX">Sturdy Shelves</part>
|
|
</parts>
|
|
|
|
</purchaseReport>
|
|
</pre></div></div><p>
|
|
The report lists, by number and quantity, the parts billed
|
|
to various zip codes, and it provides a description of each
|
|
part mentioned. In summarizing the billing data, the
|
|
intention of the report is clear and the data is
|
|
unambiguous because a number of constraints are in effect.
|
|
For example, each zip code appears only once (uniqueness
|
|
constraint). Similarly, the description of every billed
|
|
part appears only once although parts may be billed to
|
|
several zip codes (referential constraint), see for example
|
|
part number <code>455-BX</code>. In the following sections, we'll see
|
|
how to specify these constraints using XML Schema.
|
|
</p><div class="exampleOuter"><a id="report.xsd" name="report.xsd"/><div class="exampleHeader">Example</div><div class="exampleWrapper">The Report Schema, report.xsd</div><div class="exampleInner"><pre>
|
|
<schema targetNamespace="http://www.example.com/Report"
|
|
xmlns="http://www.w3.org/2001/XMLSchema"
|
|
xmlns:r="http://www.example.com/Report"
|
|
xmlns:xipo="http://www.example.com/IPO"
|
|
elementFormDefault="qualified">
|
|
|
|
<!-- for SKU -->
|
|
<import namespace="http://www.example.com/IPO"/>
|
|
|
|
<annotation>
|
|
<documentation xml:lang="en">
|
|
Report schema for Example.com
|
|
Copyright 2000 Example.com. All rights reserved.
|
|
</documentation>
|
|
</annotation>
|
|
|
|
<element name="purchaseReport">
|
|
<complexType>
|
|
<sequence>
|
|
<element name="regions" type="r:RegionsType"/>
|
|
|
|
<element name="parts" type="r:PartsType"/>
|
|
</sequence>
|
|
<attribute name="period" type="duration"/>
|
|
<attribute name="periodEnding" type="date"/>
|
|
</complexType>
|
|
|
|
<unique name="dummy1">
|
|
<selector xpath="r:regions/r:zip"/>
|
|
<field xpath="@code"/>
|
|
</unique>
|
|
|
|
<key name="pNumKey">
|
|
<selector xpath="r:parts/r:part"/>
|
|
<field xpath="@number"/>
|
|
</key>
|
|
|
|
<keyref name="dummy2" refer="r:pNumKey">
|
|
<selector xpath="r:regions/r:zip/r:part"/>
|
|
<field xpath="@number"/>
|
|
</keyref>
|
|
|
|
</element>
|
|
|
|
<complexType name="RegionsType">
|
|
<sequence>
|
|
<element name="zip" maxOccurs="unbounded">
|
|
<complexType>
|
|
<sequence>
|
|
<element name="part" maxOccurs="unbounded">
|
|
<complexType>
|
|
<complexContent>
|
|
<restriction base="anyType">
|
|
<attribute name="number" type="xipo:SKU"/>
|
|
<attribute name="quantity" type="positiveInteger"/>
|
|
</restriction>
|
|
</complexContent>
|
|
</complexType>
|
|
</element>
|
|
</sequence>
|
|
<attribute name="code" type="positiveInteger"/>
|
|
</complexType>
|
|
</element>
|
|
</sequence>
|
|
</complexType>
|
|
|
|
<complexType name="PartsType">
|
|
<sequence>
|
|
<element name="part" maxOccurs="unbounded">
|
|
<complexType>
|
|
<simpleContent>
|
|
<extension base="string">
|
|
<attribute name="number" type="xipo:SKU"/>
|
|
</extension>
|
|
</simpleContent>
|
|
</complexType>
|
|
</element>
|
|
</sequence>
|
|
</complexType>
|
|
|
|
</schema>
|
|
</pre></div></div><div class="div2">
|
|
<h3><span class="nav"> <a class="nav" href="#specifyingKeysAndtheirRefs"><img src="next.jpg" alt="next sub-section"/></a></span><a id="specifyingUniqueness" name="specifyingUniqueness"/>5.1 Specifying Uniqueness</h3><p id="ref29">XML Schema enables us to indicate
|
|
that any attribute or element value must be unique within a
|
|
certain scope. To indicate that one particular attribute or
|
|
element value is unique, we use the <code><a href="#element-unique">unique</a></code> element first to
|
|
"select" a set of elements, and then to identify the
|
|
attribute or element "field" relative to each selected
|
|
element that has to be unique within the scope of the set
|
|
of selected elements. In the case of our report schema,
|
|
<code><a href="#report.xsd">report.xsd</a></code>, the
|
|
<code><a href="#element-selector">selector</a></code>
|
|
element's <code><a href="#attribute-xpath">xpath</a></code>
|
|
attribute contains an XPath expression,
|
|
<code>r:</code><code>regions/</code><code>r:</code><code>zip</code>,
|
|
that selects a list of all the
|
|
<code>zip</code> elements in a report instance. Likewise, the
|
|
<code><a href="#element-field">field</a></code> element's
|
|
<code><a href="#attribute-xpath">xpath</a></code> attribute
|
|
contains a second XPath expression, <code>@code</code>,
|
|
that specifies that the <code>code</code> attribute values
|
|
of those elements must be unique. Note that the XPath
|
|
expressions limit the scope of what must be unique. The
|
|
report might contain another <code>code</code> attribute,
|
|
but its value does not have to be unique because it lies
|
|
outside the scope defined by the XPath expressions. Also
|
|
note that the XPath expressions you can use in the
|
|
<code><a href="#attribute-xpath">xpath</a></code> attribute
|
|
are limited to a <a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#coss-identity-constraint">subset</a>
|
|
of the full XPath language defined in <a href="http://www.w3.org/TR/1999/REC-xpath-19991116">XML Path Language 1.0</a>.
|
|
</p><p>
|
|
We can also indicate combinations of fields that
|
|
must be unique. Going
|
|
back to our purchase order example, suppose we want each item to have a
|
|
unique combination of part number and product name. We could achieve
|
|
such a constraint by specifying that for each <code>item</code> element,
|
|
the combined values of its <code>partNum</code> attribute
|
|
and its <code>productName</code> child must be unique.
|
|
</p><p>
|
|
To define combinations of values, we simply
|
|
use multiple <code> <a href="#element-field">field</a></code> elements to identify
|
|
all the values involved:
|
|
</p><div class="exampleOuter"><a id="UniqueComposedValue" name="UniqueComposedValue"/><div class="exampleHeader">Example</div><div class="exampleWrapper">A Unique Composed Value</div><div class="exampleInner"><pre>
|
|
|
|
<xsd:element name="items" type="Items">
|
|
<xsd:unique name="partNumAndName">
|
|
<xsd:selector xpath="item"/>
|
|
<xsd:field xpath="@partNum"/>
|
|
<xsd:field xpath="productName"/>
|
|
</xsd:unique>
|
|
</xsd:element>
|
|
</pre></div></div></div><div class="div2">
|
|
<h3><span class="nav"><a class="nav" href="#specifyingUniqueness"><img src="previous.jpg" alt="previous sub-section"/></a> <a class="nav" href="#schemaConstraintsVsXML1"><img src="next.jpg" alt="next sub-section"/></a></span><a id="specifyingKeysAndtheirRefs" name="specifyingKeysAndtheirRefs"/>5.2 Defining Keys & their References</h3><p id="ref30">In the 1999 quarterly report, the
|
|
description of every billed part appears only once. We
|
|
could enforce this constraint using <code><a href="#element-unique">unique</a></code>, however, we also want
|
|
to ensure that every part-quantity element listed under a
|
|
zip code has a corresponding part description. We enforce
|
|
the constraint using the <code><a href="#element-key">
|
|
key</a></code> and <code><a href="#element-keyref">
|
|
keyref</a></code> elements. The report schema, <code><a href="#report.xsd">report.xsd</a></code>, shows that the
|
|
<code><a href="#element-key">key</a></code> and <code><a href="#element-keyref">keyref</a></code> constructions are
|
|
applied using almost the same syntax as <code><a href="#element-unique">unique</a></code>. The key element
|
|
applies to the <code>number</code> attribute value of
|
|
<code>part</code> elements that are children of the <code>
|
|
parts</code> element. This declaration of <code>
|
|
number</code> as a key means that its value must be unique
|
|
and cannot be set to nil (i.e. is not nillable), and the
|
|
name that is associated with the
|
|
key, <code>pNumKey</code>, makes the key referenceable from
|
|
elsewhere.
|
|
</p><p>
|
|
To ensure that the part-quantity elements have
|
|
corresponding part descriptions, we say that the <code>
|
|
number</code> attribute (
|
|
<code><field xpath="@number"/></code>) of those
|
|
elements
|
|
(
|
|
<code><selector xpath="r:regions/r:zip/r:part"/></code>)
|
|
must reference the <code>pNumKey</code> key. This
|
|
declaration of <code>number</code> as a <code>keyref</code> does not
|
|
mean that its value must be unique, but it does mean there
|
|
must exist a <code>pNumKey</code> with the same value.
|
|
</p><p>
|
|
As you may have figured out by analogy with <code><a href="#element-unique">unique</a></code>, it is possible to
|
|
define combinations of <code><a href="#element-key">
|
|
key</a></code> and <code><a href="#element-keyref">
|
|
keyref</a></code> values. Using this mechanism, we could go
|
|
beyond simply requiring the product numbers to be equal,
|
|
and define a combination of values that must be equal. Such
|
|
values may involve combinations of multiple value types
|
|
(<code><a href="#string">string</a></code>, <code> <a href="#integer">integer</a></code>, <code><a href="#date">
|
|
date</a></code>, etc.), provided that the order and type of
|
|
the <code><a href="#element-field">field</a></code> element
|
|
references is the same in both the <code><a href="#element-key">key</a></code> and <code><a href="#element-keyref">keyref</a></code> definitions.
|
|
</p></div><div class="div2">
|
|
<h3><span class="nav"><a class="nav" href="#specifyingKeysAndtheirRefs"><img src="previous.jpg" alt="previous sub-section"/></a> <a class="nav" href="#import"><img src="next.jpg" alt="next sub-section"/></a></span><a id="schemaConstraintsVsXML1" name="schemaConstraintsVsXML1"/>5.3 XML Schema Constraints vs. XML 1.0 ID Attributes</h3><p>
|
|
<a href="http://www.w3.org/TR/2000/REC-xml-20001006">XML 1.0</a>
|
|
provides a mechanism for ensuring uniqueness using
|
|
the ID attribute and its associated attributes IDREF and
|
|
IDREFS. This mechanism is also provided in XML Schema
|
|
through the <code><a href="#ID">ID</a></code>, <code><a href="#IDREF">IDREF</a></code>, and <code> <a href="#IDREFS">IDREFS</a></code> simple types which can be used
|
|
for declaring XML 1.0-style attributes. XML Schema also
|
|
introduces new mechanisms that are more flexible and
|
|
powerful. For example, XML Schema's mechanisms can be
|
|
applied to any element and attribute content, regardless of
|
|
its type. In contrast, ID is a type of <em>attribute</em>
|
|
and so it cannot be applied to attributes, elements or
|
|
their content. Furthermore, Schema enables you to specify
|
|
the scope within which uniqueness applies whereas the scope
|
|
of an ID is fixed to be the whole document. Finally, Schema
|
|
enables you to create <code><a href="#element-key">
|
|
key</a></code>s or a <code> <a href="#element-keyref">
|
|
keyref</a></code> from combinations of element and
|
|
attribute content whereas ID has no such facility.
|
|
</p></div><div class="div2">
|
|
<h3 class="withToc"><span class="nav"><a class="nav" href="#schemaConstraintsVsXML1"><img src="previous.jpg" alt="previous sub-section"/></a> <a class="nav" href="#any"><img src="next.jpg" alt="next sub-section"/></a></span><a id="import" name="import"/>5.4 Importing Types</h3><p id="ref41">The report schema, <code><a href="#report.xsd">report.xsd</a></code>, makes use of the
|
|
simple type <code>xipo:SKU</code> that is defined in
|
|
another schema, and in another target
|
|
namespace. Recall that we used <code><a href="#element-include">include</a></code> so that the schema in
|
|
<code><a href="#ipo.xsd">ipo.xsd</a></code> could make use
|
|
of definitions and declarations from <code><a href="#address.xsd">address.xsd</a></code>. We cannot use <code>
|
|
<a href="#element-include">include</a></code> here because
|
|
it can only pull in definitions and declarations from a
|
|
schema whose target namespace is the same as the including
|
|
schema's target namespace. Hence, the <code><a href="#element-include">include</a></code> element does not
|
|
identify a namespace (although it does require a <code><a href="#attribute-schemaLocation">
|
|
schemaLocation</a></code>). The import mechanism that we
|
|
describe in this section is an important mechanism that
|
|
enables schema components from different target namespaces
|
|
to be used together, and hence enables the schema
|
|
validation of instance content defined across multiple
|
|
namespaces.
|
|
</p><p id="ref31">To import the type <code>SKU</code>
|
|
and use it in the report schema, we identify the namespace
|
|
in which <code>SKU</code> is defined, and associate that
|
|
namespace with a prefix for use in the report schema.
|
|
Concretely, we use the <code><a href="#element-import">
|
|
import</a></code> element to identify <code>SKU</code>'s
|
|
target namespace, <code>http://www.example.com/IPO</code>,
|
|
and we associate the namespace with the prefix <code>
|
|
xipo</code> using a standard namespace declaration. The
|
|
simple type <code> SKU</code>, defined in the namespace
|
|
<code> http://www.example.com/IPO</code>, may then be
|
|
referenced as <code>xipo:SKU</code> in any of the report
|
|
schema's definitions and declarations.
|
|
</p><p>
|
|
In our example, we imported one simple type from one
|
|
external namespace, and used it for declaring attributes.
|
|
XML Schema in fact permits multiple schema components to be
|
|
imported, from multiple namespaces, and they can be
|
|
referred to in both definitions and declarations. For
|
|
example in <code><a href="#report.xsd">
|
|
report.xsd</a></code> we could additionally reuse the
|
|
<code>comment</code> element declared in <code> <a href="#ipo.xsd">ipo.xsd</a></code> by referencing that element
|
|
in a declaration:
|
|
</p><div class="exampleOuter"><div class="exampleHeader">Example</div><div class="exampleInner"><pre>
|
|
<element ref="xipo:comment"/>
|
|
</pre></div></div><p>
|
|
Note however, that we cannot reuse the <code>shipTo</code>
|
|
element from <code><a href="#ipo.xsd">ipo.xsd</a></code>, and
|
|
the following is not legal because only <em>global</em> schema
|
|
components can be imported:
|
|
</p><div class="exampleOuter"><div class="exampleHeader">Example</div><div class="exampleInner"><pre>
|
|
<element ref="xipo:shipTo"/>
|
|
</pre></div></div><p>
|
|
In <code><a href="#ipo.xsd">ipo.xsd</a></code>, <code>
|
|
comment</code> is declared as a global element, in other
|
|
words it is declared as an element of the <code><a href="#element-schema">schema</a></code>. In contrast, <code>
|
|
shipTo</code> is declared locally, in other words it is an
|
|
element declared inside a complex type definition,
|
|
specifically the <code> PurchaseOrderType</code> type.
|
|
</p><p>
|
|
Complex types can also be imported, and they can be used
|
|
as the base types for deriving new types. Only named
|
|
complex types can be imported; local, anonymously defined
|
|
types cannot. Suppose we want to include in our reports the
|
|
name of an analyst, along with contact information. We can
|
|
reuse the (globally defined) complex type <code>
|
|
USAddress</code> from <code> <a href="#address.xsd">
|
|
address.xsd</a></code>, and extend it to define a new type
|
|
called <code>Analyst</code> in the report
|
|
schema by adding the new elements
|
|
<code> phone</code> and <code>email</code>:
|
|
</p><div class="exampleOuter"><a id="DefiningAnalystByExtending" name="DefiningAnalystByExtending"/><div class="exampleHeader">Example</div><div class="exampleWrapper">Defining Analyst by Extending USAddress</div><div class="exampleInner"><pre>
|
|
<complexType name="Analyst">
|
|
<complexContent>
|
|
<extension base="xipo:USAddress">
|
|
<sequence>
|
|
<element name="phone" type="string"/>
|
|
<element name="email" type="string"/>
|
|
</sequence>
|
|
</extension>
|
|
</complexContent>
|
|
</complexType>
|
|
</pre></div></div><p>
|
|
Using this new type we declare an element called <code>
|
|
analyst</code> as part of the <code>purchaseReport</code>
|
|
element declaration (declarations not shown) in the report
|
|
schema. Then, the following instance document would conform
|
|
to the modified report schema:
|
|
</p><div class="exampleOuter"><a id="InstanceWithAnalyst" name="InstanceWithAnalyst"/><div class="exampleHeader">Example</div><div class="exampleWrapper">Instance Document Conforming to Report Schema with
|
|
Analyst Type</div><div class="exampleInner"><pre>
|
|
<r:purchaseReport
|
|
xmlns:r="http://www.example.com/Report"
|
|
period="P3M" periodEnding="1999-12-31">
|
|
<!-- regions and parts elements omitted -->
|
|
<r:analyst>
|
|
<name>Wendy Uhro</name>
|
|
<street>10 Corporate Towers</street>
|
|
<city>San Jose</city>
|
|
<state>CA</state>
|
|
<zip>95113</zip>
|
|
<r:phone>408-271-3366</r:phone>
|
|
<r:email>uhro@example.com</r:email>
|
|
</r:analyst>
|
|
</r:purchaseReport>
|
|
</pre></div></div><p>
|
|
Note that the report now has both qualified and unqualified elements. This
|
|
is because some of the elements (<code>name</code>, <code>street</code>, <code>city</code>,
|
|
<code>state</code> and <code>zip</code>) are locally declared in <code><a href="#ipo.xsd">ipo.xsd</a></code>, whose
|
|
<code>elementFormDefault</code> is <code>unqualified</code> (by default). The other elements in the
|
|
example are declared in <code><a href="#report.xsd">report.xsd</a></code>, whose <code>elementFormDefault</code> is set to <code>qualified</code>.
|
|
</p><p>
|
|
When schema components are imported from multiple
|
|
namespaces, each namespace must be identified with a
|
|
separate <code><a href="#element-import">import</a></code>
|
|
element. The <code> <a href="#element-import">
|
|
import</a></code> elements themselves must appear as the
|
|
first children of the <code><a href="#element-schema">
|
|
schema</a></code> element. Furthermore, each namespace must
|
|
be associated with a prefix, using a standard namespace
|
|
declaration, and that prefix is used to qualify references
|
|
to any schema components belonging to that namespace.
|
|
Finally, <code><a href="#element-import">import</a></code>
|
|
elements optionally contain a <code><a href="#attribute-schemaLocation">schemaLocation</a></code>
|
|
attribute to help locate resources associated with the
|
|
namespaces. We discuss the <code><a href="#attribute-schemaLocation">schemaLocation</a></code>
|
|
attribute in more detail in a later section.
|
|
</p><div class="div3">
|
|
<h4><a id="Libs" name="Libs"/>5.4.1 Type Libraries</h4><p>
|
|
As XML schemas become more widespread, schema authors will
|
|
want to create simple and complex types that can be shared
|
|
and used as building blocks for creating new
|
|
schemas. XML Schemas already provides types that play this
|
|
role, in particular, the types described in the <a href="#SimpleTypeFacets">Simple Types appendix</a> and in an
|
|
introductory <a href="http://www.w3.org/2001/03/XMLSchema/TypeLibrary.xsd">
|
|
type library</a>.
|
|
</p><p>
|
|
Schema authors will undoubtedly want to create their own
|
|
libraries of types to represent currency, units of measurement,
|
|
business addresses, and so on. Each library might consist of a
|
|
schema containing one or more definitions, for example, a schema
|
|
containing a currency type:
|
|
</p><div class="exampleOuter"><a id="ExampleCurrencyType" name="ExampleCurrencyType"/><div class="exampleHeader">Example</div><div class="exampleWrapper">Example Currency Type in Type Library</div><div class="exampleInner"><pre>
|
|
<schema targetNamespace="http://www.example.com/Currency"
|
|
xmlns:c="http://www.example.com/Currency"
|
|
xmlns="http://www.w3.org/2001/XMLSchema">
|
|
|
|
<annotation>
|
|
<documentation xml:lang="en">
|
|
Definition of Currency type based on ISO 4217
|
|
</documentation>
|
|
</annotation>
|
|
|
|
<complexType name="Currency">
|
|
<simpleContent>
|
|
<extension base="decimal">
|
|
<attribute name="name">
|
|
<simpleType>
|
|
<restriction base="string">
|
|
|
|
<enumeration value="AED">
|
|
<annotation>
|
|
<documentation xml:lang="en">
|
|
United Arab Emirates: Dirham (1 Dirham = 100 Fils)
|
|
</documentation>
|
|
</annotation>
|
|
</enumeration>
|
|
|
|
<enumeration value="AFA">
|
|
<annotation>
|
|
<documentation xml:lang="en">
|
|
Afghanistan: Afghani (1 Afghani = 100 Puls)
|
|
</documentation>
|
|
</annotation>
|
|
</enumeration>
|
|
|
|
<enumeration value="ALL">
|
|
<annotation>
|
|
<documentation xml:lang="en">
|
|
Albania, Lek (1 Lek = 100 Qindarka)
|
|
</documentation>
|
|
</annotation>
|
|
</enumeration>
|
|
|
|
<!-- and other currencies -->
|
|
|
|
</restriction>
|
|
</simpleType>
|
|
</attribute>
|
|
</extension>
|
|
</simpleContent>
|
|
</complexType>
|
|
|
|
</schema>
|
|
</pre></div></div><p>
|
|
An example of an element appearing in an instance and
|
|
having this type:
|
|
</p><div class="exampleOuter"><div class="exampleHeader">Example</div><div class="exampleInner"><pre>
|
|
<convertFrom name="AFA">199.37</convertFrom>
|
|
</pre></div></div><p>
|
|
Once we have defined the currency type, we can make it
|
|
available for re-use in other schemas through the <code><a href="#element-import">import</a></code> mechanism just
|
|
described.
|
|
</p></div></div><div class="div2">
|
|
<h3><span class="nav"><a class="nav" href="#import"><img src="previous.jpg" alt="previous sub-section"/></a> <a class="nav" href="#schemaLocation"><img src="next.jpg" alt="next sub-section"/></a></span><a id="any" name="any"/>5.5 Any Element, Any Attribute</h3><p>
|
|
In previous sections we have seen several mechanisms for
|
|
extending the content models of complex types. For example,
|
|
a mixed content model can contain arbitrary character data
|
|
in addition to elements, and for example, a content model
|
|
can contain elements whose types are imported
|
|
from external namespaces. However, these mechanisms provide
|
|
very broad and very narrow controls respectively. The
|
|
purpose of this section is to describe a flexible mechanism
|
|
that enables content models to be extended by any elements
|
|
and attributes belonging to specified namespaces.
|
|
</p><p>
|
|
To illustrate, consider a version of the quarterly report,
|
|
<code><a href="#Q99html.xml">4Q99html.xml</a></code>, in
|
|
which we have embedded an XHTML representation of the XML
|
|
parts data. The XHTML content appears as the content of the
|
|
element <code> htmlExample</code>, and the default
|
|
namespace is changed on the outermost XHTML element
|
|
(<code>table</code>) so that all the XHTML elements belong
|
|
to the XHTML namespace, <code>
|
|
http://www.w3.org/1999/xhtml</code>:
|
|
</p><div class="exampleOuter"><a id="Q99html.xml" name="Q99html.xml"/><div class="exampleHeader">Example</div><div class="exampleWrapper">Quarterly Report with
|
|
XHTML, 4Q99html.xml</div><div class="exampleInner"><pre>
|
|
<purchaseReport
|
|
xmlns="http://www.example.com/Report"
|
|
period="P3M" periodEnding="1999-12-31">
|
|
|
|
<regions>
|
|
<!-- part sales listed by zip code, data from 4Q99.xml -->
|
|
</regions>
|
|
|
|
<parts>
|
|
<!-- part descriptions from 4Q99.xml -->
|
|
</parts>
|
|
|
|
<htmlExample>
|
|
<table xmlns="http://www.w3.org/1999/xhtml"
|
|
border="0" width="100%">
|
|
<tr>
|
|
<th align="left">Zip Code</th>
|
|
<th align="left">Part Number</th>
|
|
<th align="left">Quantity</th>
|
|
</tr>
|
|
<tr><td>95819</td><td> </td><td> </td></tr>
|
|
<tr><td> </td><td>872-AA</td><td>1</td></tr>
|
|
<tr><td> </td><td>926-AA</td><td>1</td></tr>
|
|
<tr><td> </td><td>833-AA</td><td>1</td></tr>
|
|
<tr><td> </td><td>455-BX</td><td>1</td></tr>
|
|
<tr><td>63143</td><td> </td><td> </td></tr>
|
|
<tr><td> </td><td>455-BX</td><td>4</td></tr>
|
|
</table>
|
|
</htmlExample>
|
|
|
|
</purchaseReport>
|
|
</pre></div></div><p id="ref32">To permit the appearance of XHTML in
|
|
the instance document we modify the report schema by
|
|
declaring a new element <code>htmlExample</code> whose
|
|
content is defined by the <code><a href="#element-any">
|
|
any</a></code> element. In general, an <code><a href="#element-any">any</a></code> element specifies that any
|
|
well-formed XML is permissible in a type's content model.
|
|
In the example, we require the XML to belong to the
|
|
namespace <code> http://www.w3.org/1999/xhtml</code>, in
|
|
other words, it should be XHTML. The example also requires
|
|
there to be at least one element present from this
|
|
namespace, as indicated by the values of <code><a href="#attribute-minOccurs">minOccurs</a></code> and <code> <a href="#attribute-maxOccurs">maxOccurs</a></code>:
|
|
</p><div class="exampleOuter"><a id="ModificationtoPurchaseReport" name="ModificationtoPurchaseReport"/><div class="exampleHeader">Example</div><div class="exampleWrapper">Modification to purchaseReport Declaration to Allow
|
|
XHTML in Instance</div><div class="exampleInner"><pre>
|
|
<element name="purchaseReport">
|
|
<complexType>
|
|
<sequence>
|
|
<element name="regions" type="r:RegionsType"/>
|
|
<element name="parts" type="r:PartsType"/>
|
|
<element name="htmlExample">
|
|
<complexType>
|
|
<sequence>
|
|
<any namespace="http://www.w3.org/1999/xhtml"
|
|
minOccurs="1" maxOccurs="unbounded"
|
|
processContents="skip"/>
|
|
</sequence>
|
|
</complexType>
|
|
</element>
|
|
</sequence>
|
|
<attribute name="period" type="duration"/>
|
|
<attribute name="periodEnding" type="date"/>
|
|
</complexType>
|
|
</element>
|
|
</pre></div></div><p id="ref33">The modification permits some
|
|
well-formed XML belonging to the namespace <code>
|
|
http://www.w3.org/1999/xhtml</code> to appear inside the
|
|
<code>htmlExample</code> element. Therefore <code><a href="#Q99html.xml">4Q99html.xml</a></code> is permissible
|
|
because there is one element which (with its children) is
|
|
well-formed, the element appears inside the appropriate
|
|
element (<code>htmlExample</code>), and the instance
|
|
document asserts that the element and its content belongs
|
|
to the required namespace. However, the XHTML may not
|
|
actually be valid because nothing in <code><a href="#Q99html.xml">4Q99html.xml</a></code> by itself can
|
|
provide that guarantee. If such a guarantee is required,
|
|
the value of the <code><a href="#attribute-processContents">processContents</a></code>
|
|
attribute should be set to <code>strict</code>
|
|
(the default value). In this case, an XML processor is
|
|
obliged to obtain the schema associated with the required
|
|
namespace, and validate the XHTML appearing within the
|
|
<code>htmlExample</code> element.
|
|
</p><p id="textType">In another example, we define a <code>text</code>
|
|
type which is
|
|
similar to the text type defined in XML Schema's introductory <a href="http://www.w3.org/2001/03/XMLSchema/TypeLibrary.xsd">
|
|
type library</a> (see also <a href="#Libs">Type Libraries (§5.4.1)</a>), and
|
|
is suitable for internationalized human-readable text. The
|
|
text type allows an unrestricted mixture of character content
|
|
and element content from any namespace, for example <a href="http://www.w3.org/TR/ruby/">Ruby</a> annotations, along with
|
|
an optional <code>xml:lang</code> attribute. The <code>lax</code>
|
|
value of the
|
|
<code><a href="#attribute-processContents">processContents</a></code>
|
|
attribute instructs an XML processor to validate the element
|
|
content on a can-do basis: It will validate elements and attributes for
|
|
which it can obtain schema information, but it will not signal errors
|
|
for those it cannot obtain any schema information.
|
|
</p><div class="exampleOuter"><a id="TextTypeNote" name="TextTypeNote"/><div class="exampleHeader">Example</div><div class="exampleWrapper">Text Type</div><div class="exampleInner"><pre>
|
|
<xsd:complexType name="text">
|
|
<xsd:complexContent mixed="true">
|
|
<xsd:restriction base="xsd:anyType">
|
|
<xsd:sequence>
|
|
<xsd:any processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
|
|
</xsd:sequence>
|
|
<xsd:attribute ref="xml:lang"/>
|
|
</xsd:restriction>
|
|
</xsd:complexContent>
|
|
</xsd:complexType>
|
|
</pre></div></div><p id="ref34">Namespaces may be used to permit and
|
|
forbid element content in various ways depending upon the
|
|
value of the <code><a href="#attribute-namespace">
|
|
namespace</a></code> attribute, as shown in <a href="#nsTable">Table 4</a>:
|
|
</p><a id="nsTable" name="nsTable"/><table summary="namespace attribute in any" width="100%" border="2"><tbody><tr><th colspan="2" align="left">Table 4. Namespace Attribute in Any</th></tr><tr><th>Value of Namespace Attribute</th><th>Allowable Element Content</th></tr><tr><td>##any</td><td>Any well-formed XML from any namespace (default)</td></tr><tr><td>##local</td><td>Any well-formed XML that is not qualified, i.e. not
|
|
declared to be in a namespace</td></tr><tr><td>##other</td><td>Any well-formed XML that is from a namespace other
|
|
than the target
|
|
namespace of the type being defined (unqualified
|
|
elements are not allowed)</td></tr><tr><td>"http://www.w3.org/1999/xhtml ##targetNamespace"</td><td>Any well-formed XML belonging to any namespace in the
|
|
(whitespace separated) list; ##targetNamespace is
|
|
shorthand for the target namespace of the type being
|
|
defined</td></tr></tbody></table><p id="ref35">In addition to the <code><a href="#element-any">any</a></code> element which enables element
|
|
content according to namespaces, there is a corresponding
|
|
<code><a href="#element-anyAttribute">
|
|
anyAttribute</a></code> element which enables attributes to
|
|
appear in elements. For example, we can permit any XHTML
|
|
attribute to appear as part of the <code>htmlExample</code>
|
|
element by adding <code> <a href="#element-anyAttribute">
|
|
anyAttribute</a></code> to its declaration:
|
|
</p><div class="exampleOuter"><a id="ModificationToHTMLExample" name="ModificationToHTMLExample"/><div class="exampleHeader">Example</div><div class="exampleWrapper">Modification to htmlExample Declaration to Allow XHTML
|
|
Attributes</div><div class="exampleInner"><pre>
|
|
<element name="htmlExample">
|
|
<complexType>
|
|
<sequence>
|
|
<any namespace="http://www.w3.org/1999/xhtml"
|
|
minOccurs="1" maxOccurs="unbounded"
|
|
processContents="skip"/>
|
|
</sequence>
|
|
<anyAttribute namespace="http://www.w3.org/1999/xhtml"/>
|
|
</complexType>
|
|
</element>
|
|
</pre></div></div><p>
|
|
This declaration permits an XHTML attribute, say <code>
|
|
href</code>, to appear in the <code>htmlExample</code>
|
|
element. For example:
|
|
</p><div class="exampleOuter"><a id="AnXHTMLAttribute" name="AnXHTMLAttribute"/><div class="exampleHeader">Example</div><div class="exampleWrapper">An XHTML attribute in the htmlExample Element</div><div class="exampleInner"><pre>
|
|
....
|
|
<htmlExample xmlns:h="http://www.w3.org/1999/xhtml"
|
|
h:href="http://www.example.com/reports/4Q99.html">
|
|
<!-- XHTML markup here -->
|
|
</htmlExample>
|
|
....
|
|
</pre></div></div><p>
|
|
The <code><a href="#attribute-namespace">
|
|
namespace</a></code> attribute in an <code> <a href="#element-anyAttribute">anyAttribute</a></code> element can
|
|
be set to any of the values listed in <a href="#nsTable">
|
|
Table 4</a> for the <code> <a href="#element-any">
|
|
any</a></code> element, and <code><a href="#element-anyAttribute">anyAttribute</a></code> can be
|
|
specified with a <code><a href="#attribute-processContents">processContents</a></code>
|
|
attribute. In contrast to an <code><a href="#element-any">
|
|
any</a></code> element, <code> <a href="#element-anyAttribute">anyAttribute</a></code> cannot
|
|
constrain the number of attributes that may appear in an
|
|
element.
|
|
</p></div><div class="div2">
|
|
<h3><span class="nav"><a class="nav" href="#any"><img src="previous.jpg" alt="previous sub-section"/></a> <a class="nav" href="#conformance"><img src="next.jpg" alt="next sub-section"/></a></span><a id="schemaLocation" name="schemaLocation"/>5.6 schemaLocation</h3><p>
|
|
XML Schema uses the <code><a href="#attribute-schemaLocation">schemaLocation</a></code> and
|
|
<code><a href="#attribute-xsischemaLocation">
|
|
xsi:schemaLocation</a></code> attributes in three
|
|
circumstances.
|
|
</p><p id="ref40">1. In an instance document, the
|
|
attribute <code> <a href="#attribute-xsischemaLocation">
|
|
xsi:schemaLocation</a></code> provides hints from the
|
|
author to a processor regarding the location of schema
|
|
documents. The author warrants that these schema documents
|
|
are relevant to checking the validity of the document
|
|
content, on a namespace by namespace basis. For example, we
|
|
can indicate the location of the Report schema to a
|
|
processor of the Quarterly Report:
|
|
</p><div class="exampleOuter"><a id="UsingSchemaLocationInQuarterly" name="UsingSchemaLocationInQuarterly"/><div class="exampleHeader">Example</div><div class="exampleWrapper">Using schemaLocation in the Quarterly Report,
|
|
4Q99html.xml</div><div class="exampleInner"><pre>
|
|
<purchaseReport
|
|
xmlns="http://www.example.com/Report"
|
|
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
|
|
xsi:schemaLocation="http://www.example.com/Report
|
|
http://www.example.com/Report.xsd"
|
|
period="P3M" periodEnding="1999-12-31">
|
|
|
|
<!-- etc. -->
|
|
|
|
</purchaseReport>
|
|
</pre></div></div><p>
|
|
|
|
The <code><a href="#attribute-schemaLocation">schemaLocation</a></code>
|
|
attribute value consists of one or more pairs of URI references,
|
|
separated by white space. The first member of each pair is a namespace
|
|
name, and the second member of the pair is a hint describing where to
|
|
find an appropriate schema document for that namespace.
|
|
The presence of
|
|
these hints does not require the processor to obtain or use
|
|
the cited schema documents, and the processor is free to
|
|
use other schemas obtained by any suitable means, or to use
|
|
no schema at all.
|
|
</p><p>
|
|
A schema is not required to have a namespace (see <a href="#UndeclaredTNS">Undeclared Target Namespaces (§3.4)</a>) and so there is a <code>
|
|
<a href="#attribute-noNamespaceSchemaLocation">
|
|
noNamespaceSchemaLocation</a></code> attribute which is
|
|
used to provide hints for the locations of schema documents
|
|
that do not have target namespaces.
|
|
</p><p>
|
|
2. In a schema, the <code><a href="#element-include">
|
|
include</a></code> element has a required <code><a href="#attribute-schemaLocation">schemaLocation</a></code>
|
|
attribute, and it contains a URI reference which must
|
|
identify a schema document. The effect is to compose a
|
|
final effective schema by merging the declarations and
|
|
definitions of the including and the included schemas. For
|
|
example, in <a href="#IPO">Advanced Concepts II: The International Purchase Order (§4)</a>, the type
|
|
definitions of <code>Address</code>, <code>
|
|
USAddress</code>, <code>UKAddress</code>, <code>
|
|
USState</code> (along with their attribute and local
|
|
element declarations) from <code><a href="#address.xsd">
|
|
address.xsd</a></code> were added to the element
|
|
declarations of <code>purchaseOrder</code> and <code>
|
|
comment</code>, and the type definitions of <code>
|
|
PurchaseOrderType</code>, <code>Items</code> and <code>
|
|
SKU</code> (along with their attribute and local element
|
|
declarations) from <code><a href="#ipo.xsd">
|
|
ipo.xsd</a></code> to create a single schema.
|
|
</p><p>
|
|
3. Also in a schema, the <code><a href="#element-import">
|
|
import</a></code> element has optional <code><a href="#attribute-namespace">namespace</a></code> and <code><a href="#attribute-schemaLocation">schemaLocation</a></code>
|
|
attributes. If present, the <code><a href="#attribute-schemaLocation">schemaLocation</a></code>
|
|
attribute is understood in a way which parallels the
|
|
interpretation of <code> <a href="#attribute-xsischemaLocation">
|
|
xsi:schemaLocation</a></code> in (1). Specifically, it
|
|
provides a hint from the author to a processor regarding
|
|
the location of a schema document that the author warrants
|
|
supplies the required components for the namespace
|
|
identified by the <code><a href="#attribute-namespace">
|
|
namespace</a></code> attribute. To import components that
|
|
are not in any target namespace, the <code><a href="#element-import">import</a></code> element is used without
|
|
a <code><a href="#attribute-namespace">namespace</a></code>
|
|
attribute (and with or without a <code><a href="#attribute-schemaLocation">schemaLocation</a></code>
|
|
attribute). References to components imported in this
|
|
manner are unqualified.
|
|
</p><p>
|
|
Note that the <code><a href="#attribute-schemaLocation">
|
|
schemaLocation</a></code> is only a hint and some
|
|
processors and applications will have reasons to not use
|
|
it. For example, an XHTML editor may have a built-in XHTML
|
|
schema.
|
|
</p></div><div class="div2">
|
|
<h3><span class="nav"><a class="nav" href="#schemaLocation"><img src="previous.jpg" alt="previous sub-section"/></a> </span><a id="conformance" name="conformance"/>5.7 Conformance</h3><p>
|
|
An instance document may be processed against a schema to
|
|
verify whether the rules specified in the schema are
|
|
honored in the instance. Typically, such processing
|
|
actually does two things, (1) it checks for conformance to
|
|
the rules, a process called schema validation, and (2) it
|
|
adds supplementary information that is not immediately
|
|
present in the instance, such as types and default values,
|
|
called infoset contributions.
|
|
</p><p>
|
|
The author of an instance document, such as a particular
|
|
purchase order, may claim, in the instance itself, that it
|
|
conforms to the rules in a particular schema. The author
|
|
does this using the <code><a href="#attribute-schemaLocation">schemaLocation</a></code>
|
|
attribute discussed above. But regardless of whether a
|
|
<code> <a href="#attribute-schemaLocation">
|
|
schemaLocation</a></code> attribute is present, an
|
|
application is free to process the document against any
|
|
schema. For example, a purchasing application may have the
|
|
policy of always using a certain purchase order schema,
|
|
regardless of any <code><a href="#attribute-schemaLocation">schemaLocation</a></code>
|
|
values.
|
|
</p><p>
|
|
Conformance checking can be thought of as proceeding in
|
|
steps, first checking that the root element of the document
|
|
instance has the right contents, then checking that each
|
|
subelement conforms to its description in a schema, and so
|
|
on until the entire document is verified. Processors are
|
|
required to report what checking has been carried out.
|
|
</p><p>
|
|
To check an element for conformance, the processor first
|
|
locates the declaration for the element in a schema, and
|
|
then checks that the <code><a href="#attribute-targetNamespace">targetNamespace</a></code>
|
|
attribute in the schema matches the actual namespace URI of
|
|
the element. Alternatively, it may determine that the schema does not
|
|
have a <code><a href="#attribute-targetNamespace">
|
|
targetNamespace</a></code> attribute and the instance
|
|
element is not namespace-qualified.
|
|
</p><p>
|
|
Supposing the namespaces match, the processor then
|
|
examines the type of the element, either as given by the
|
|
declaration in the schema, or by an <code><a href="#attribute-xsitype">xsi:type</a></code> attribute in the
|
|
instance. If the latter, the instance type must be an
|
|
allowed substitution for the type given in the schema; what
|
|
is allowed is controlled by the <code> <a href="#attribute-block">block</a></code> attribute in the
|
|
element declaration. At this same time, default values and
|
|
other infoset contributions are applied.
|
|
</p><p>
|
|
Next the processor checks the immediate attributes and
|
|
contents of the element, comparing these against the
|
|
attributes and contents permitted by the element's type.
|
|
For example, considering a <code>shipTo</code> element such
|
|
as the one in <a href="#POSchema">The Purchase Order Schema (§2.1)</a>, the
|
|
processor checks what is permitted for an <code>
|
|
Address</code>, because that is the <code>shipTo</code>
|
|
element's type.
|
|
</p><p>
|
|
If the element has a simple type, the processor verifies
|
|
that the element has no attributes or contained elements,
|
|
and that its character content matches the rules for the
|
|
simple type. This sometimes involves checking the character
|
|
sequence against regular expressions or enumerations, and
|
|
sometimes it involves checking that the character sequence
|
|
represents a value in a permitted range.
|
|
</p><p>
|
|
If the element has a complex type, then the processor
|
|
checks that any required attributes are present and that
|
|
their values conform to the requirements of their simple
|
|
types. It also checks that all required subelements are
|
|
present, and that the sequence of subelements (and any
|
|
mixed text) matches the content model declared for the
|
|
complex type. Regarding subelements, schemas can either
|
|
require exact name matching, permit substitution by an
|
|
equivalent element or permit substitution by any element
|
|
allowed by an 'any' particle.
|
|
</p><p>
|
|
Unless a schema indicates otherwise (as it can for 'any'
|
|
particles) conformance checking then proceeds one level
|
|
more deeply by looking at each subelement in turn,
|
|
repeating the process described above.
|
|
</p></div></div></div><div class="back"><div class="div1">
|
|
<h2><a id="Acks" name="Acks"/>A Acknowledgements</h2><p>
|
|
Many people have contributed ideas, material and feedback
|
|
that has improved this document. In particular, the editor
|
|
acknowledges contributions from David Beech,
|
|
Paul Biron, Don Box, Allen Brown, David Cleary, Dan
|
|
Connolly, Roger Costello, Martin Dürst, Martin Gudgin, Dave Hollander,
|
|
Joe Kesselman, John McCarthy, Andrew Layman, Eve Maler,
|
|
Ashok Malhotra, Noah Mendelsohn, Michael Sperberg-McQueen,
|
|
Henry Thompson, Misha Wolf, and Priscilla Walmsley for
|
|
validating the examples.
|
|
</p><p>At the time the first edition of this
|
|
specification was published, the members of the XML Schema Working Group
|
|
were:</p><ul><li>Jim Barnette, Defense Information Systems Agency (DISA)</li><li>Paul V. Biron, Health Level Seven</li><li>Don Box, DevelopMentor</li><li>Allen Brown, Microsoft</li><li>Lee Buck, TIBCO Extensibility</li><li>Charles E. Campbell, Informix</li><li>Wayne Carr, Intel</li><li>Peter Chen, Bootstrap Alliance and LSU</li><li>David Cleary, Progress Software</li><li>Dan Connolly, W3C (<i>staff contact</i>) </li><li>Ugo Corda, Xerox</li><li>Roger L. Costello, MITRE</li><li>Haavard Danielson, Progress Software</li><li>Josef Dietl, Mozquito Technologies</li><li>David Ezell, Hewlett-Packard Company
|
|
</li><li>Alexander Falk, Altova GmbH</li><li>David Fallside, IBM</li><li>Dan Fox, Defense Logistics Information Service (DLIS)</li><li>Matthew Fuchs, Commerce One</li><li>Andrew Goodchild, Distributed Systems Technology Centre (DSTC Pty Ltd)</li><li>Paul Grosso, Arbortext, Inc</li><li>Martin Gudgin, DevelopMentor</li><li>Dave Hollander, Contivo, Inc (<i>co-chair</i>) </li><li>Mary Holstege, Invited Expert</li><li>Jane Hunter, Distributed Systems Technology Centre (DSTC Pty Ltd)</li><li>Rick Jelliffe, Academia Sinica</li><li>Simon Johnston, Rational Software</li><li>Bob Lojek, Mozquito Technologies</li><li>Ashok Malhotra, Microsoft</li><li>Lisa Martin, IBM</li><li>Noah Mendelsohn, Lotus Development Corporation</li><li>Adrian Michel, Commerce One</li><li>Alex Milowski, Invited Expert</li><li>Don Mullen, TIBCO Extensibility</li><li>Dave Peterson, Graphic Communications Association</li><li>Jonathan Robie, Software AG</li><li>Eric Sedlar, Oracle Corp.</li><li>C. M. Sperberg-McQueen, W3C (<i>co-chair</i>) </li><li>Bob Streich, Calico Commerce</li><li>William K. Stumbo, Xerox</li><li>Henry S. Thompson, University of Edinburgh</li><li>Mark Tucker, Health Level Seven</li><li>Asir S. Vedamuthu, webMethods, Inc</li><li>Priscilla Walmsley, XMLSolutions</li><li>Norm Walsh, Sun Microsystems</li><li>Aki Yoshida, SAP AG</li><li>Kongyi Zhou, Oracle Corp.</li></ul><p>The XML Schema Working Group has benefited in its work from the
|
|
participation and contributions of a number of people not currently
|
|
members of the Working Group, including
|
|
in particular those named below. Affiliations given are those current at
|
|
the time of their work with the WG.
|
|
</p><ul><li>Paula Angerstein, Vignette Corporation</li><li>David Beech, Oracle Corp.</li><li>Gabe Beged-Dov, Rogue Wave Software</li><li>Greg Bumgardner, Rogue Wave Software</li><li>Dean Burson, Lotus Development Corporation</li><li>Mike Cokus, MITRE</li><li>Andrew Eisenberg, Progress Software</li><li>Rob Ellman, Calico Commerce</li><li>George Feinberg, Object Design</li><li>Charles Frankston, Microsoft</li><li>Ernesto Guerrieri, Inso</li><li>Michael Hyman, Microsoft</li><li>Renato Iannella, Distributed Systems Technology Centre (DSTC Pty Ltd)</li><li>Dianne Kennedy, Graphic Communications Association</li><li>Janet Koenig, Sun Microsystems</li><li>Setrag Khoshafian, Technology Deployment International (TDI)</li><li>Ara Kullukian, Technology Deployment International (TDI)</li><li>Andrew Layman, Microsoft</li><li>Dmitry Lenkov, Hewlett-Packard Company</li><li>John McCarthy, Lawrence Berkeley National Laboratory</li><li>Murata Makoto, Xerox</li><li>Eve Maler, Sun Microsystems</li><li>Murray Maloney, Muzmo Communication, acting for Commerce One</li><li>Chris Olds, Wall Data</li><li>Frank Olken, Lawrence Berkeley National Laboratory</li><li>Shriram Revankar, Xerox</li><li>Mark Reinhold, Sun Microsystems</li><li>John C. Schneider, MITRE</li><li>Lew Shannon, NCR</li><li>William Shea, Merrill Lynch</li><li>Ralph Swick, W3C</li><li>Tony Stewart, Rivcom</li><li>Matt Timmermans, Microstar</li><li>Jim Trezzo, Oracle Corp.</li><li>Steph Tryphonas, Microstar</li></ul><p>The lists given above pertain to the first edition.
|
|
At the time work on this second edition was completed,
|
|
the membership of the Working Group was:</p><ul><li>Leonid Arbouzov, Sun Microsystems</li><li>Jim Barnette, Defense Information Systems Agency (DISA)</li><li>Paul V. Biron, Health Level Seven</li><li>Allen Brown, Microsoft</li><li>Charles E. Campbell, Invited expert</li><li>Peter Chen, Invited expert</li><li>Tony Cincotta, NIST</li><li>David Ezell, National Association of Convenience Stores</li><li>Matthew Fuchs, Invited expert</li><li>Sandy Gao, IBM</li><li>Andrew Goodchild, Distributed Systems Technology Centre (DSTC Pty Ltd)</li><li>Xan Gregg, Invited expert</li><li>Mary Holstege, Mark Logic</li><li>Mario Jeckle, DaimlerChrysler</li><li>Marcel Jemio, Data Interchange Standards Association</li><li>Kohsuke Kawaguchi, Sun Microsystems</li><li>Ashok Malhotra, Invited expert</li><li>Lisa Martin, IBM</li><li>Jim Melton, Oracle Corp</li><li>Noah Mendelsohn, IBM</li><li>Dave Peterson, Invited expert</li><li>Anli Shundi, TIBCO Extensibility</li><li>C. M. Sperberg-McQueen, W3C (<i>co-chair</i>) </li><li>Hoylen Sue, Distributed Systems Technology Centre (DSTC Pty Ltd)</li><li>Henry S. Thompson, University of Edinburgh</li><li>Asir S. Vedamuthu, webMethods, Inc</li><li>Priscilla Walmsley, Invited expert</li><li>Kongyi Zhou, Oracle Corp.</li></ul><p>
|
|
We note with sadness the accidental death of Mario Jeckle
|
|
shortly after the completion of work on this document.
|
|
In addition to those named above, several
|
|
people served on the Working Group during the development
|
|
of this second edition:
|
|
</p><ul><li>Oriol Carbo, University of Edinburgh</li><li>Tyng-Ruey Chuang, Academia Sinica</li><li>Joey Coyle, Health Level 7</li><li>Tim Ewald, DevelopMentor</li><li>Nelson Hung, Corel</li><li>Melanie Kudela, Uniform Code Council</li><li>Matthew MacKenzie, XML Global</li><li>Cliff Schmidt, Microsoft</li><li>John Stanton, Defense Information Systems Agency</li><li>John Tebbutt, NIST</li><li>Ross Thompson, Contivo</li><li>Scott Vorthmann, TIBCO Extensibility</li></ul></div><div class="div1">
|
|
<h2><a id="SimpleTypeFacets" name="SimpleTypeFacets"/>B Simple Types & their Facets</h2><p>
|
|
The legal values for each simple type can be constrained
|
|
through the application of one or more facets. Tables <a href="#facetsTable1">B1.a</a>
|
|
and <a href="#facetsTable2">B1.b</a> list all of XML Schema's built-in simple types
|
|
and the facets applicable to each type. The names of the
|
|
simple types and the facets are linked from the tables to
|
|
the corresponding descriptions in <a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html">XML
|
|
Schema Part 2: Datatypes</a>.
|
|
</p><a id="facetsTable1" name="facetsTable1"/><table summary="simple types and their facets" width="100%" border="2"><tbody><tr><th colspan="7" align="left">Table B1.a. Simple Types & Applicable Facets</th></tr><tr><th>Simple Types</th><th colspan="6">Facets</th></tr><tr><th/><th><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#rf-length">length</a></th><th><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#rf-minLength">minLength</a></th><th><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#rf-maxLength">maxLength</a></th><th><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#rf-pattern">pattern</a></th><th><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#rf-enumeration">enumeration</a></th><th><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#rf-whiteSpace">whiteSpace</a></th></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#string">string</a></td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#normalizedString">normalizedString</a></td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#token">token</a></td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">see (1)</td></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#base64Binary">base64Binary</a></td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">see (1)</td></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#hexBinary">hexBinary</a></td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">see (1)</td></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#integer">integer</a></td><td align="center"/><td align="center"/><td align="center"/><td align="center">y</td><td align="center">y</td><td align="center">see (1)</td></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#positiveInteger">positiveInteger</a></td><td align="center"/><td align="center"/><td align="center"/><td align="center">y</td><td align="center">y</td><td align="center">see (1)</td></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#negativeInteger">negativeInteger</a></td><td align="center"/><td align="center"/><td align="center"/><td align="center">y</td><td align="center">y</td><td align="center">see (1)</td></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#nonNegativeInteger">nonNegativeInteger</a></td><td align="center"/><td align="center"/><td align="center"/><td align="center">y</td><td align="center">y</td><td align="center">see (1)</td></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#nonPositiveInteger">nonPositiveInteger</a></td><td align="center"/><td align="center"/><td align="center"/><td align="center">y</td><td align="center">y</td><td align="center">see (1)</td></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#long">long</a></td><td align="center"/><td align="center"/><td align="center"/><td align="center">y</td><td align="center">y</td><td align="center">see (1)</td></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#unsignedLong">unsignedLong</a></td><td align="center"/><td align="center"/><td align="center"/><td align="center">y</td><td align="center">y</td><td align="center">see (1)</td></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#int">int</a></td><td align="center"/><td align="center"/><td align="center"/><td align="center">y</td><td align="center">y</td><td align="center">see (1)</td></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#unsignedInt">unsignedInt</a></td><td align="center"/><td align="center"/><td align="center"/><td align="center">y</td><td align="center">y</td><td align="center">see (1)</td></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#short">short</a></td><td align="center"/><td align="center"/><td align="center"/><td align="center">y</td><td align="center">y</td><td align="center">see (1)</td></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#unsignedShort">unsignedShort</a></td><td align="center"/><td align="center"/><td align="center"/><td align="center">y</td><td align="center">y</td><td align="center">see (1)</td></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#byte">byte</a></td><td align="center"/><td align="center"/><td align="center"/><td align="center">y</td><td align="center">y</td><td align="center">see (1)</td></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#unsignedByte">unsignedByte</a></td><td align="center"/><td align="center"/><td align="center"/><td align="center">y</td><td align="center">y</td><td align="center">see (1)</td></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#decimal">decimal</a></td><td align="center"/><td align="center"/><td align="center"/><td align="center">y</td><td align="center">y</td><td align="center">see (1)</td></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#float">float</a></td><td align="center"/><td align="center"/><td align="center"/><td align="center">y</td><td align="center">y</td><td align="center">see (1)</td></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#double">double</a></td><td align="center"/><td align="center"/><td align="center"/><td align="center">y</td><td align="center">y</td><td align="center">see (1)</td></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#boolean">boolean</a></td><td/><td/><td/><td align="center">y</td><td/><td align="center">see (1)</td></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#duration">duration</a></td><td align="center"/><td align="center"/><td align="center"/><td align="center">y</td><td align="center">y</td><td align="center">see (1)</td></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#dateTime">dateTime</a></td><td align="center"/><td align="center"/><td align="center"/><td align="center">y</td><td align="center">y</td><td align="center">see (1)</td></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#date">date</a></td><td align="center"/><td align="center"/><td align="center"/><td align="center">y</td><td align="center">y</td><td align="center">see (1)</td></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#time">time</a></td><td align="center"/><td align="center"/><td align="center"/><td align="center">y</td><td align="center">y</td><td align="center">see (1)</td></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#gYear">gYear</a></td><td align="center"/><td align="center"/><td align="center"/><td align="center">y</td><td align="center">y</td><td align="center">see (1)</td></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#gYearMonth">gYearMonth</a></td><td align="center"/><td align="center"/><td align="center"/><td align="center">y</td><td align="center">y</td><td align="center">see (1)</td></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#gMonth">gMonth</a></td><td align="center"/><td align="center"/><td align="center"/><td align="center">y</td><td align="center">y</td><td align="center">see (1)</td></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#gMonthDay">gMonthDay</a></td><td align="center"/><td align="center"/><td align="center"/><td align="center">y</td><td align="center">y</td><td align="center">see (1)</td></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#gDay">gDay</a></td><td align="center"/><td align="center"/><td align="center"/><td align="center">y</td><td align="center">y</td><td align="center">see (1)</td></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#Name">Name</a></td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">see (1)</td></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#QName">QName</a></td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">see (1)</td></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#NCName">NCName</a></td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">see (1)</td></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#anyURI">anyURI</a></td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">see (1)</td></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#language">language</a></td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">see (1)</td></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#ID">ID</a></td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">see (1)</td></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#IDREF">IDREF</a></td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">see (1)</td></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#IDREFS">IDREFS</a></td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">see (1)</td></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#ENTITY">ENTITY</a></td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">see (1)</td></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#ENTITIES">ENTITIES</a></td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">see (1)</td></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#NOTATION">NOTATION</a></td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">see (1)</td></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#NMTOKEN">NMTOKEN</a></td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">see (1)</td></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#NMTOKENS">NMTOKENS</a></td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">see (1)</td></tr><tr><td colspan="7">Note: (1) Although the <code>whiteSpace</code> facet is
|
|
applicable to this type, the only value that can be specified is <code>collapse</code>.</td></tr></tbody></table><p>
|
|
The facets listed in Table B1.b apply only to simple types
|
|
which are ordered. Not all simple types are ordered and so
|
|
B1.b does not list all of the simple types.
|
|
</p><a id="facetsTable2" name="facetsTable2"/><table summary="ordered simple types and their facets" width="100%" border="2"><tbody><tr><th colspan="9" align="left">Table B1.b. Simple Types & Applicable Facets</th></tr><tr><th>Simple Types</th><th colspan="8">Facets</th></tr><tr><th/><th>
|
|
<table border="0"><tbody><tr><th align="center"><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#rf-maxInclusive">max</a></th></tr><tr><th align="center"><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#rf-maxInclusive">Inclusive</a></th></tr></tbody></table>
|
|
</th><th>
|
|
<table border="0"><tbody><tr><th align="center"><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#rf-maxExclusive">max</a></th></tr><tr><th align="center"><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#rf-maxExclusive">Exclusive</a></th></tr></tbody></table>
|
|
</th><th>
|
|
<table border="0"><tbody><tr><th align="center"><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#rf-minInclusive">min</a></th></tr><tr><th align="center"><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#rf-minInclusive">Inclusive</a></th></tr></tbody></table>
|
|
</th><th>
|
|
<table border="0"><tbody><tr><th align="center"><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#rf-minExclusive">min</a></th></tr><tr><th align="center"><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#rf-minExclusive">Exclusive</a></th></tr></tbody></table>
|
|
</th><th>
|
|
<table border="0"><tbody><tr><th align="center"><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#rf-totalDigits">total</a></th></tr><tr><th align="center"><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#rf-totalDigits">Digits</a></th></tr></tbody></table>
|
|
</th><th>
|
|
<table border="0"><tbody><tr><th align="center"><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#rf-fractionDigits">fraction</a></th></tr><tr><th align="center"><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#rf-fractionDigits">Digits</a></th></tr></tbody></table>
|
|
</th></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#integer">integer</a></td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">see (1)</td></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#positiveInteger">positiveInteger</a></td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">see (1)</td></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#negativeInteger">negativeInteger</a></td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">see (1)</td></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#nonNegativeInteger">nonNegativeInteger</a></td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">see (1)</td></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#nonPositiveInteger">nonPositiveInteger</a></td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">see (1)</td></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#long">long</a></td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">see (1)</td></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#unsignedLong">unsignedLong</a></td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">see (1)</td></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#int">int</a></td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">see (1)</td></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#unsignedInt">unsignedInt</a></td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">see (1)</td></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#short">short</a></td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">see (1)</td></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#unsignedShort">unsignedShort</a></td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">see (1)</td></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#byte">byte</a></td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">see (1)</td></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#unsignedByte">unsignedByte</a></td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">see (1)</td></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#decimal">decimal</a></td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#float">float</a></td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center"/><td align="center"/></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#double">double</a></td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center"/><td align="center"/></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#duration">duration</a></td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center"/><td align="center"/></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#dateTime">dateTime</a></td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center"/><td align="center"/></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#date">date</a></td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center"/><td align="center"/></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#time">time</a></td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center"/><td align="center"/></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#gYear">gYear</a></td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center"/><td align="center"/></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#gYearMonth">gYearMonth</a></td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center"/><td align="center"/></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#gMonth">gMonth</a></td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center"/><td align="center"/></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#gMonthDay">gMonthDay</a></td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center"/><td align="center"/></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#gDay">gDay</a></td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center">y</td><td align="center"/><td align="center"/></tr><tr><td colspan="7">
|
|
Note: (1) Although the <code>fractionDigits</code> facet is
|
|
applicable to this type, the only value that can be specified is zero.</td></tr></tbody></table></div><div class="div1">
|
|
<h2><a id="usingEntities" name="usingEntities"/>C Using Entities</h2><p>
|
|
XML 1.0 provides various types of entities which are named
|
|
fragments of content that can be used in the construction
|
|
of both DTD's (parameter entities) and instance documents.
|
|
In <a href="#groups">Building Content Models (§2.7)</a>, we noted how named
|
|
groups mimic parameter entities. In this section we show
|
|
how entities can be declared in instance documents, and how
|
|
the functional equivalents of entities can be declared in
|
|
schemas.
|
|
</p><p>
|
|
Suppose we want to declare and use an entity in an
|
|
instance document, and that document is also constrained by
|
|
a schema. For example:
|
|
</p><div class="exampleOuter"><a id="DeclaringAndReferencingAnEntity" name="DeclaringAndReferencingAnEntity"/><div class="exampleHeader">Example</div><div class="exampleWrapper">Declaring and referencing an entity in an instance
|
|
document.</div><div class="exampleInner"><pre>
|
|
<?xml version="1.0" ?>
|
|
<!DOCTYPE purchaseOrder [
|
|
<!ENTITY eacute "&#xE9;">
|
|
]>
|
|
<purchaseOrder xmlns="http://www.example.com/PO1"
|
|
orderDate="1999-10-20">
|
|
<!-- etc. -->
|
|
<city>Montr&eacute;al</city>
|
|
<!-- etc. -->
|
|
</purchaseOrder>
|
|
</pre></div></div><p>
|
|
Here, we declare an entity called <code>eacute</code> as
|
|
part of an internal (DTD) subset, and we reference this
|
|
entity in the content of the <code>city</code> element.
|
|
Note that when this instance document is processed, the
|
|
entity will be
|
|
resolved
|
|
before schema validation takes
|
|
place. In other words, a schema processor will determine
|
|
the validity of the <code>city</code> element using <code>
|
|
Montréal</code> as the element's value.
|
|
</p><p>
|
|
We can achieve a similar but not identical outcome by
|
|
declaring an element in a schema, and by setting the
|
|
element's content appropriately:
|
|
</p><div class="exampleOuter"><div class="exampleHeader">Example</div><div class="exampleInner"><pre>
|
|
<xsd:element name="eacute" type="xsd:token" fixed="&#xE9;"/>
|
|
</pre></div></div><p>
|
|
And this element can be used in an instance document:
|
|
</p><div class="exampleOuter"><a id="UsingAnElementInsteadOfAnEntity" name="UsingAnElementInsteadOfAnEntity"/><div class="exampleHeader">Example</div><div class="exampleWrapper">Using an element instead of an entity in an instance
|
|
document.</div><div class="exampleInner"><pre>
|
|
<?xml version="1.0" ?>
|
|
<purchaseOrder xmlns="http://www.example.com/PO1"
|
|
xmlns:c="http://www.example.com/characterElements"
|
|
orderDate="1999-10-20">
|
|
<!-- etc. -->
|
|
<city>Montr<c:eacute/>al</city>
|
|
<!-- etc. -->
|
|
</purchaseOrder>
|
|
</pre></div></div><p>
|
|
In this case, a schema processor will process two
|
|
elements, a <code>city</code> element, and an <code>
|
|
eacute</code> element for the contents of which the
|
|
processor will supply the single character <code>
|
|
é</code>. Note that the extra element will
|
|
complicate string matching; the two forms of the name
|
|
"Montréal" given in the two examples above will not
|
|
match each other using normal string-comparison techniques.
|
|
</p></div><div class="div1">
|
|
<h2><a id="regexAppendix" name="regexAppendix"/>D Regular Expressions</h2><p>
|
|
XML Schema's <code><a href="#element-pattern">
|
|
pattern</a></code> facet uses a regular expression language
|
|
that supports <a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#UnicodeDB">
|
|
Unicode</a>. It is fully described in <a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#regexs">
|
|
XML Schema Part 2</a>. The language is similar to the
|
|
regular expression language used in the <a href="http://www.perldoc.com/perl5.6/pod/perlre.html"> Perl
|
|
Programming language</a>, although expressions are matched
|
|
against entire lexical representations rather than
|
|
user-scoped lexical representations such as line and
|
|
paragraph. For this reason, the expression language does
|
|
not contain the metacharacters ^ and $, although ^ is used
|
|
to express exception, e.g. [^0-9]x.
|
|
</p><a id="regexTable" name="regexTable"/><table summary="regex examples" width="100%" border="2"><tbody><tr><th colspan="2" align="left">Table D1. Examples of Regular Expressions</th></tr><tr><td>Expression</td><td>Match(es)</td></tr><tr><td>Chapter \d</td><td>Chapter 0, Chapter 1, Chapter 2 ....</td></tr><tr><td>Chapter\s\d</td><td>Chapter followed by a single whitespace character
|
|
(space, tab, newline, etc.), followed by a single
|
|
digit</td></tr><tr><td>Chapter\s\w</td><td>Chapter followed by a single whitespace character
|
|
(space, tab, newline, etc.), followed by a word
|
|
character (<a href="http://www.w3.org/TR/2000/REC-xml-20001006#CharClasses">XML 1.0
|
|
Letter or Digit</a>)</td></tr><tr><td>Espa&#xF1;ola</td><td>Española</td></tr><tr><td>\p{Lu}</td><td>any uppercase character, the value of \p{} (e.g.
|
|
"Lu") is defined by <a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#UnicodeDB">Unicode</a></td></tr><tr><td>\p{IsGreek}</td><td>any Greek character, the 'Is' construction may be
|
|
applied to any block name (e.g. "Greek") as defined
|
|
by <a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#UnicodeDB">Unicode</a></td></tr><tr><td>\P{IsGreek}</td><td>any non-Greek character, the 'Is' construction may be
|
|
applied to any block name (e.g. "Greek") as defined
|
|
by <a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#UnicodeDB">Unicode</a></td></tr><tr><td>a*x</td><td>x, ax, aax, aaax ....</td></tr><tr><td>a?x</td><td>ax, x</td></tr><tr><td>a+x</td><td>ax, aax, aaax ....</td></tr><tr><td>(a|b)+x</td><td>ax, bx, aax, abx, bax, bbx, aaax, aabx, abax, abbx,
|
|
baax, babx, bbax, bbbx, aaaax ....</td></tr><tr><td>[abcde]x</td><td>ax, bx, cx, dx, ex</td></tr><tr><td>[a-e]x</td><td>ax, bx, cx, dx, ex</td></tr><tr><td>[\-ae]x</td><td>-x, ax, ex</td></tr><tr><td>[ae\-]x</td><td>ax, ex, -x</td></tr><tr><td>[^0-9]x</td><td>any non-digit character followed by the character x</td></tr><tr><td>\Dx</td><td>any non-digit character followed by the character x</td></tr><tr><td>.x</td><td>any character followed by the character x</td></tr><tr><td>.*abc.*</td><td>1x2abc, abc1x2, z3456abchooray ....</td></tr><tr><td>ab{2}x</td><td>abbx</td></tr><tr><td>ab{2,4}x</td><td>abbx, abbbx, abbbbx</td></tr><tr><td>ab{2,}x</td><td>abbx, abbbx, abbbbx ....</td></tr><tr><td>(ab){2}x</td><td>ababx</td></tr></tbody></table></div><div class="div1">
|
|
<h2><a id="index" name="index"/>E Index</h2><div class="div2">
|
|
<h3><span class="nav"> <a class="nav" href="#indexAttr"><img src="next.jpg" alt="next sub-section"/></a></span><a id="indexEl" name="indexEl"/>E.1 XML Schema Elements</h3><p>Each element name is followed by one or more links to examples
|
|
(identified by section number) in the Primer
|
|
, plus a link to a formal XML description in either the
|
|
Structures or Datatypes parts of the XML Schema
|
|
specification.
|
|
</p><table cellspacing="3" cellpadding="3" border="0"><tbody><tr><td id="element-all"><code>all</code>:
|
|
[<a href="#ref18"> (§2.7)</a>]
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-all">Structures</a>]</td></tr><tr><td id="element-annotation"><code>annotation</code>:
|
|
[<a href="#ref16"> (§2.6)</a>]
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-annotation">Structures</a>]</td></tr><tr><td id="element-any"><code>any</code>:
|
|
[<a href="#ref32"> (§5.5)</a>]
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-any">Structures</a>]</td></tr><tr><td id="element-anyAttribute"><code>anyAttribute</code>:
|
|
[<a href="#ref35"> (§5.5)</a>]
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-anyAttribute">Structures</a>]</td></tr><tr><td id="element-appinfo"><code>appinfo</code>:
|
|
[<a href="#ref15"> (§2.6)</a>]
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-appinfo">Structures</a>]</td></tr><tr><td id="element-attribute"><code>attribute</code>:
|
|
[<a href="#ref2"> (§2.2)</a>]
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-attribute">Structures</a>]</td></tr><tr><td id="element-attributeGroup"><code>attributeGroup</code>:
|
|
[<a href="#ref19"> (§2.8)</a>]
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-attributeGroup">Structures</a>]</td></tr><tr><td id="element-choice"><code>choice</code>:
|
|
[<a href="#ref17"> (§2.7)</a>]
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-choice">Structures</a>]</td></tr><tr><td id="element-complexContent"><code>complexContent</code>:
|
|
[<a href="#ref13"> (§2.5.3)</a>]
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-complexContent">Structures</a>]</td></tr><tr><td id="element-complexType"><code>complexType</code>:
|
|
[<a href="#ref2"> (§2.2)</a>]
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-complexType">Structures</a>]</td></tr><tr><td id="element-documentation"><code>documentation</code>:
|
|
[<a href="#ref14"> (§2.6)</a>]
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-documentation">Structures</a>]</td></tr><tr><td id="element-element"><code>element</code>:
|
|
[<a href="#ref2"> (§2.2)</a>]
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-element">Structures</a>]</td></tr><tr><td id="element-enumeration"><code>enumeration</code>:
|
|
[<a href="#ref10"> (§2.3)</a>]
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#element-enumeration">Datatypes</a>]</td></tr><tr><td id="element-extension"><code>extension</code>:
|
|
[<a href="#ref37"> (§2.5.1)</a>]
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-simpleContent..extension">Structures</a>],
|
|
[<a href="#ref53"> (§4.2)</a>]
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-complexContent..extension">Structures</a>]</td></tr><tr><td id="element-field"><code>field</code>:
|
|
[<a href="#ref29"> (§5.1)</a>]
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-field">Structures</a>]</td></tr><tr><td id="element-group"><code>group</code>:
|
|
[<a href="#ref17"> (§2.7)</a>]
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-group">Structures</a>]</td></tr><tr><td id="element-import"><code>import</code>:
|
|
[<a href="#ref31"> (§5.4)</a>]
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-import">Structures</a>]</td></tr><tr><td id="element-include"><code>include</code>:
|
|
[<a href="#ref23"> (§4.1)</a>]
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-include">Structures</a>]</td></tr><tr><td id="element-key"><code>key</code>:
|
|
[<a href="#ref30"> (§5.2)</a>]
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-key">Structures</a>]</td></tr><tr><td id="element-keyref"><code>keyref</code>:
|
|
[<a href="#ref30"> (§5.2)</a>]
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-keyref">Structures</a>]</td></tr><tr><td id="element-length"><code>length</code>:
|
|
[<a href="#ref12"> (§2.3.1)</a>]
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#element-length">Datatypes</a>]</td></tr><tr><td id="element-list"><code>list</code>:
|
|
[<a href="#ref45"> (§2.3.1)</a>]
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#element-list">Datatypes</a>]</td></tr><tr><td id="element-maxInclusive"><code>maxInclusive</code>:
|
|
[<a href="#ref8"> (§2.3)</a>]
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#element-maxInclusive">Datatypes</a>]</td></tr><tr><td id="element-maxLength"><code>maxLength</code>:
|
|
[<a href="#ref12"> (§2.3.1)</a>]
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#element-maxLength">Datatypes</a>]</td></tr><tr><td id="element-minInclusive"><code>minInclusive</code>:
|
|
[<a href="#ref8"> (§2.3)</a>]
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#element-minInclusive">Datatypes</a>]</td></tr><tr><td id="element-minLength"><code>minLength</code>:
|
|
[<a href="#ref12"> (§2.3.1)</a>]
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#element-minLength">Datatypes</a>]</td></tr><tr><td id="element-pattern"><code>pattern</code>:
|
|
[<a href="#ref9"> (§2.3)</a>]
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#element-pattern">Datatypes</a>]</td></tr><tr><td id="element-redefine"><code>redefine</code>:
|
|
[<a href="#ref52"> (§4.5)</a>]
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-redefine">Structures</a>]</td></tr><tr><td id="element-restriction"><code>restriction</code>:
|
|
[<a href="#ref7"> (§2.3)</a>]
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#element-restriction">Datatypes</a>],
|
|
[<a href="#ref54"> (§4.4)</a>]
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-restriction">Structures</a>]</td></tr><tr><td id="element-schema"><code>schema</code>:
|
|
[<a href="#ref1"> (§2.1)</a>]
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-schema">Structures</a>]</td></tr><tr><td id="element-selector"><code>selector</code>:
|
|
[<a href="#ref29"> (§5.1)</a>]
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-selector">Structures</a>]</td></tr><tr><td id="element-sequence"><code>sequence</code>:
|
|
[<a href="#ref17"> (§2.7)</a>]
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-sequence">Structures</a>]</td></tr><tr><td id="element-simpleContent"><code>simpleContent</code>:
|
|
[<a href="#ref37"> (§2.5.1)</a>]
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-simpleContent">Structures</a>]</td></tr><tr><td id="element-simpleType"><code>simpleType</code>:
|
|
[<a href="#ref7"> (§2.3)</a>]
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#element-simpleType">Datatypes</a>]</td></tr><tr><td id="element-union"><code>union</code>:
|
|
[<a href="#ref46"> (§2.3.2)</a>]
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#element-union">Datatypes</a>]</td></tr><tr><td id="element-unique"><code>unique</code>:
|
|
[<a href="#ref29"> (§5.1)</a>]
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-unique">Structures</a>]</td></tr></tbody></table></div><div class="div2">
|
|
<h3><span class="nav"><a class="nav" href="#indexEl"><img src="previous.jpg" alt="previous sub-section"/></a> </span><a id="indexAttr" name="indexAttr"/>E.2 XML Schema Attributes</h3><p>Each attribute name is
|
|
followed by one or more pairs of references. Each pair of
|
|
references consists of a link to an example in the Primer,
|
|
plus a link to a formal XML description in either the
|
|
Structures or Datatypes parts of the XML Schema
|
|
specification.
|
|
</p><table cellpadding="3" cellspacing="3"><tbody><tr><td id="attribute-abstract"><code>abstract</code>:
|
|
<a href="#ref26">element declaration</a>
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-element">Structures</a>]</td></tr><tr><td><code>abstract</code>:
|
|
<a href="#ref26">complex type definition</a>
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-complexType">Structures</a>]</td></tr><tr><td id="attribute-attributeFormDefault"><code>attributeFormDefault</code>:
|
|
<a href="#ref50">schema definition</a>
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-schema">Structures</a>]</td></tr><tr><td id="attribute-base"><code>base</code>:
|
|
<a href="#ref8">simple type definition</a>
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#element-simpleType">Datatypes</a>]</td></tr><tr><td><code>base</code>:
|
|
<a href="#ref37">complex type definition</a>
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-complexType">Structures</a>]</td></tr><tr><td id="attribute-block"><code>block</code>:
|
|
<a href="#ref28">complex type definition</a>
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-complexType">Structures</a>]</td></tr><tr><td id="attribute-blockDefault"><code>blockDefault</code>:
|
|
<a href="#ref42">schema definition</a>
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-schema">Structures</a>]</td></tr><tr><td id="attribute-attr-default"><code>default</code>:
|
|
<a href="#ref36">attribute declaration</a>
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-attribute">Structures</a>]</td></tr><tr><td id="attribute-default"><code>default</code>:
|
|
<a href="#ref36">element declaration</a>
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-element">Structures</a>]</td></tr><tr><td id="attribute-elementFormDefault"><code>elementFormDefault</code>:
|
|
<a href="#ref50">schema definition</a>
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-schema">Structures</a>]</td></tr><tr><td id="attribute-final"><code>final</code>:
|
|
<a href="#ref27">complex type definition</a>
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-complexType">Structures</a>]</td></tr><tr><td id="attribute-finalDefault"><code>finalDefault</code>:
|
|
<a href="#ref43">schema definition</a>
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-schema">Structures</a>]</td></tr><tr><td id="attribute-attr-fixed"><code>fixed</code>:
|
|
<a href="#ref55">attribute declaration</a>
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-attribute">Structures</a>]</td></tr><tr><td id="attribute-fixed"><code>fixed</code>:
|
|
<a href="#ref55">element declaration</a>
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-element">Structures</a>]</td></tr><tr><td id="attribute-facet-fixed"><code>fixed</code>:
|
|
<a href="#ref44">simple type definition</a>
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#rf-facets">Datatypes</a>]</td></tr><tr><td id="attribute-form"><code>form</code>:
|
|
<a href="#ref39">attribute declaration</a>
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-attribute">Structures</a>]</td></tr><tr><td><code>form</code>:
|
|
<a href="#ref39">element declaration</a>
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-element">Structures</a>]</td></tr><tr><td id="attribute-itemType"><code>itemType</code>:
|
|
<a href="#ref45">list type definition</a>
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#element-list">Datatypes</a>]</td></tr><tr><td id="attribute-memberTypes"><code>memberTypes</code>:
|
|
<a href="#ref46">union type definition</a>
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#element-union">Datatypes</a>]</td></tr><tr><td id="attribute-maxOccurs"><code>maxOccurs</code>:
|
|
<a href="#ref6">element declaration</a>
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-element">Structures</a>]</td></tr><tr><td id="attribute-minOccurs"><code>minOccurs</code>:
|
|
<a href="#ref6">element declaration</a>
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-element">Structures</a>]</td></tr><tr><td id="attribute-mixed"><code>mixed</code>:
|
|
<a href="#ref51">complex type definition</a>
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-complexType">Structures</a>]</td></tr><tr><td id="attribute-name"><code>name</code>:
|
|
<a href="#ref3">element declaration</a>
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-element">Structures</a>]</td></tr><tr><td><code>name</code>:
|
|
<a href="#ref2">attribute declaration</a>
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-attribute">Structures</a>]</td></tr><tr><td><code>name</code>:
|
|
<a href="#ref2">complex type definition</a>
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-complexType">Structures</a>]</td></tr><tr><td><code>name</code>:
|
|
<a href="#ref8">simple type definition</a>
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#element-simpleType">Datatypes</a>]</td></tr><tr><td id="attribute-namespace"><code>namespace</code>:
|
|
<a href="#ref34">element wildcard</a>
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-any">Structures</a>]</td></tr><tr><td><code>namespace</code>:
|
|
<a href="#ref31">import specification</a>
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-include">Structures</a>]</td></tr><tr><td id="attribute-noNamespaceSchemaLocation"><code>xsi:noNamespaceSchemaLocation</code>:
|
|
<a href="#ref40">instance element</a>
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#schema-loc">Structures</a>]</td></tr><tr><td id="attribute-xsinil"><code>xsi:nil</code>:
|
|
<a href="#ref21">instance element</a>
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#xsi_nil">Structures</a>]</td></tr><tr><td id="attribute-nillable"><code>nillable</code>:
|
|
<a href="#ref20">element declaration</a>
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-element">Structures</a>]</td></tr><tr><td id="attribute-processContents"><code>processContents</code>:
|
|
<a href="#ref33">element wildcard</a>
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-any">Structures</a>]</td></tr><tr><td><code>processContents</code>:
|
|
<a href="#ref35">attribute wildcard</a>
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-anyAttribute">Structures</a>]</td></tr><tr><td id="attribute-ref"><code>ref</code>:
|
|
<a href="#ref5">element declaration</a>
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-element">Structures</a>]</td></tr><tr><td id="attribute-schemaLocation"><code>schemaLocation</code>:
|
|
<a href="#ref23">include specification</a>
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-include">Structures</a>]</td></tr><tr><td><code>schemaLocation</code>:
|
|
<a href="#ref52">redefine specification</a>
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-redefine">Structures</a>]</td></tr><tr><td><code>schemaLocation</code>:
|
|
<a href="#ref41">import specification</a>
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-import">Structures</a>]</td></tr><tr><td id="attribute-xsischemaLocation"><code>xsi:schemaLocation</code>:
|
|
<a href="#ref40">instance element</a>
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#xsi_schemaLocation">Structures</a>]</td></tr><tr><td id="attribute-subsGroup"><code>substitutionGroup</code>:
|
|
<a href="#ref25">element declaration</a>
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-element">Structures</a>]</td></tr><tr><td id="attribute-targetNamespace"><code>targetNamespace</code>:
|
|
<a href="#ref56">schema definition</a>
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-schema">Structures</a>]</td></tr><tr><td id="attribute-type"><code>type</code>:
|
|
<a href="#ref4">element declaration</a>
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-element">Structures</a>]</td></tr><tr><td><code>type</code>:
|
|
<a href="#ref4">attribute declaration</a>
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-attribute">Structures</a>]</td></tr><tr><td id="attribute-xsitype"><code>xsi:type</code>:
|
|
<a href="#ref24">instance element</a>
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#xsi_type">Structures</a>]</td></tr><tr><td id="attribute-use"><code>use</code>:
|
|
<a href="#ref36">attribute declaration</a>
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-attribute">Structures</a>]</td></tr><tr><td id="attribute-xpath"><code>xpath</code>:
|
|
<a href="#ref29">identity constraint definition</a>
|
|
[<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#declare-key">Structures</a>]</td></tr></tbody></table><p>XML Schema's simple types are described in <a href="#simpleTypesTable">Table 2</a>.
|
|
</p></div></div></div></body></html>
|