This document is also available in these non-normative formats: XML, XHTML with changes since version 1.0 marked, XHTML with changes since previous Working Draft marked, Independent copy of the schema for schema documents, Independent copy of the DTD for schema documents, Independent tabulation of components and microcomponents, and List of translations.
Copyright © 2009 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
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 W3C technical reports index at http://www.w3.org/TR/.
This ↑is a member-only review version which will in due course be published as a↑ W3C Proposed Recommendation ↓specifies↓ ↑specifying↑ W3C XML Schema Definition Language (XSD) 1.1. It ↑has no formal standing within W3C; it↑ is here made available for review by W3C members↓ and the public↓. XSD 1.1 retains all the essential features of XSD 1.0, but adds several new features to support functionality requested by users, fixes many errors in XSD 1.0, and clarifies wording. ↑ This draft was created on 28 October 2009. It reflects (unless otherwise noted elsewhere) all decisions on this document made by the Working Group through 23 October 2009. The document thus incorporates all decisions made by the Working Group to date. ↑
<xs:all> model groups.
Such
references must have minOccur=maxOccurs=1 and refer
to other <xs:all> groups.
(This change
resolves issue
7031 XSD 1.1 doesn't support conversion of xs:sequence to xs:all
because xs:all can't contain groups references.)
For those primarily interested in the changes since version 1.0, the appendix Changes since version 1.0 (non-normative) (§G) is the recommended starting point. It summarizes both changes made since XSD 1.0 and some changes which were expected (and predicted in earlier drafts of this specification) but have not been made after all. Accompanying versions of this document display in color all changes to normative text since version 1.0 and since the previous Working Draft.
The Candidate Recommendation review period for this document extends until 3 August 2009. Comments on this document should be made in W3C's public installation of Bugzilla, specifying "XML Schema" as the product. Instructions can be found at http://www.w3.org/XML/2006/01/public-bugzilla. If access to Bugzilla is not feasible, please send your comments to the W3C XML Schema comments mailing list, www-xml-schema-comments@w3.org (archive) Each Bugzilla entry and email message should contain only one comment.
Although feedback based on any aspect of this specification is welcome, there are certain aspects of the design presented herein for which the Working Group is particularly interested in feedback. These are designated "priority feedback" aspects of the design, and identified as such in editorial notes at appropriate points in this draft. Any feature mentioned in a priority feedback note is a "feature at risk": the feature may be retained as is or dropped, depending on the feedback received from readers, schema authors, schema users, and implementors.
Publication as a ↓Proposed Recommendation↓↑Editors' Draft↑ does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document has been produced by the W3C XML Schema Working Group as part of the W3C XML Activity. The goals of XSD 1.1 are discussed in the document Requirements for XML Schema 1.1. The authors of this document are the members of the XML Schema Working Group. Different parts of this specification have different editors.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; 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) must disclose the information in accordance with section 6 of the W3C Patent Policy.
The English version of this specification is the only normative version. Information about translations of this document is available at http://www.w3.org/2003/03/Translations/byTechnology?technology=xmlschema.
The presentation of this document has been augmented to
identify changes from a previous version, controlled by dg-b7813.xml. Three kinds of changes are highlighted:
↑new, added text↑,
↑changed text↓, and
↓deleted text↓.
Complex Type Definitions provide for:
The XML representation for a complex type definition schema component is a <complexType> element information item.
The XML representation for complex type definitions with a {content type} with {variety} simple is significantly different from that of those with other {content type}s, and this is reflected in the presentation below, which describes the mappings for the two cases in separate subsections. Common mapping rules are factored out and given in separate sections.
complexType Element Information Item<complexType
abstract = boolean : false
block =
(#all | List of (extension | restriction))
final =
(#all | List of (extension | restriction))
id = ID
mixed = boolean
name = NCName
defaultAttributesApply = boolean : true
{any attributes with non-schema namespace . . .}>
Content: (annotation?, (simpleContent | complexContent | (openContent?, (group | all | choice | sequence)?, ((attribute | attributeGroup)*, anyAttribute?), assert*)))
</complexType>
<complexType name="anyThing"/> is allowed.
Where convenient, the mapping rules are described exclusively in terms of the schema document's information set. The mappings, however, depend not only upon the source declaration but also upon the schema context. Some mappings, that is, depend on the properties of other components in the schema. In particular, several of the mapping rules given in the following sections depend upon the {base type definition} having been identified before they apply.
Whichever alternative for the content of <complexType> is chosen, the following property mappings apply. Except where otherwise specified, attributes and child elements are to be sought among the [attributes] and [children] of the <complexType> element.
targetNamespace [attribute] of the <schema> ancestor element information item if present,
otherwise ·absent·.block
[attribute], if present, otherwise to the ·actual value· of the
blockDefault [attribute] of the ancestor
<schema> element information item, if present,
otherwise on the empty string. Call this the
EBV (for effective block value). Then the
value of this property is
the appropriate case among the following:#all, then {extension,
restriction};blockDefault [attribute] of
<schema> may include values other than
restriction or extension, those values
are ignored in the determination of {prohibited substitutions} for complex type
definitions (they are used elsewhere).final and finalDefault
[attributes] in place of the block and
blockDefault [attributes].name [attribute] is
present, then ·absent·, otherwise (the parent
element information item will be <element>), the Element Declaration corresponding to
that parent information item.When the <complexType> source declaration has a <simpleContent> child, the following elements are relevant (as are <attribute>, <attributeGroup>, and <anyAttribute>), and the property mappings are as below, supplemented by the mappings in Common Mapping Rules for Complex Type Definitions (§3.4.2.1), Mapping Rule for Attribute Uses Property (§3.4.2.4), and Mapping Rule for Attribute Wildcard Property (§3.4.2.5). Note that either <restriction> or <extension> must appear in the content of <simpleContent>.
simpleContent Element Information Item et al.<simpleContent
id = ID
{any attributes with non-schema namespace . . .}>
Content: (annotation?, (restriction | extension))
</simpleContent>
<restriction
base = QName
id = ID
{any attributes with non-schema namespace . . .}>
Content: (annotation?, (simpleType?, (minExclusive | minInclusive | maxExclusive | maxInclusive | totalDigits | fractionDigits | maxScale | minScale | length | minLength | maxLength | enumeration | whiteSpace | pattern | assertion | {any with namespace: ##other})*)?, ((attribute | attributeGroup)*, anyAttribute?), assert*)
</restriction>
<extension
base = QName
id = ID
{any attributes with non-schema namespace . . .}>
Content: (annotation?, ((attribute | attributeGroup)*, anyAttribute?), assert*)
</extension>
When the <complexType> element has a <simpleContent> child, then the <complexType> element maps to a complex type with simple content, as follows.
base [attribute]
on the
<restriction> or
<extension> element appearing as a child of
<simpleContent>
xs:anySimpleType·) a simple type definition which
restricts SB with a set of facet
components corresponding to the appropriate element
information items among the <restriction>'s [children] (i.e. those
which specify facets, if any), as defined in Simple Type Restriction (Facets) (§3.16.6.4);
xs:anySimpleType·), the result will be a simple type definition component
which fails to obey the constraints on simple type definitions, including
for example clause 1.1 of
Derivation Valid (Restriction, Simple) (§3.16.6.2).
xs:anySimpleType·.When the <complexType> element does not have a <simpleContent> child element, then it maps to a complex type with complex content. The following elements are relevant (as are the <attribute>, <attributeGroup>, and <anyAttribute> elements, not repeated here), and the additional property mappings are as below, supplemented by the mappings in Common Mapping Rules for Complex Type Definitions (§3.4.2.1), Mapping Rule for Attribute Uses Property (§3.4.2.4), and Mapping Rule for Attribute Wildcard Property (§3.4.2.5). Note that either <restriction> or <extension> must appear in the content of <complexContent>, but their content models are different in this case from the case above when they occur as children of <simpleContent>.
complexContent Element Information Item et al.<complexContent
id = ID
mixed = boolean
{any attributes with non-schema namespace . . .}>
Content: (annotation?, (restriction | extension))
</complexContent>
<restriction
base = QName
id = ID
{any attributes with non-schema namespace . . .}>
Content: (annotation?, openContent?, (group | all | choice | sequence)?, ((attribute | attributeGroup)*, anyAttribute?), assert*)
</restriction>
<extension
base = QName
id = ID
{any attributes with non-schema namespace . . .}>
Content: (annotation?, openContent?, ((group | all | choice | sequence)?, ((attribute | attributeGroup)*, anyAttribute?), assert*))
</extension>
<openContent
id = ID
mode = (none | interleave | suffix) : interleave
{any attributes with non-schema namespace . . .}>
Content: (annotation?, any?)
</openContent>
Complex types with complex content can be the image of two different forms of <complexType> element: one with a <complexContent> child (discussed in Mapping Rules for Complex Types with Explicit Complex Content (§3.4.2.3.1)), and one with neither <simpleContent> nor <complexContent> as a child (discussed in Mapping Rules for Complex Types with Implicit Complex Content (§3.4.2.3.2)). The mapping of the {content type} is the same in both cases; it is described in Mapping Rules for Content Type Property of Complex Content (§3.4.2.3.3).
When the <complexType> source declaration has a <complexContent> child, the following mappings apply, supplemented by those specified in Mapping Rules for Content Type Property of Complex Content (§3.4.2.3.3), Common Mapping Rules for Complex Type Definitions (§3.4.2.1), Mapping Rule for Attribute Uses Property (§3.4.2.4), and Mapping Rule for Attribute Wildcard Property (§3.4.2.5).
When the <complexType> source declaration
has neither <simpleContent> nor
<complexContent> as a child, it is taken
as shorthand for complex content restricting
·xs:anyType·. The mapping rules specific to this
situation are as follows; the mapping rules for properties
not described here are as given in
Mapping Rules for Content Type Property of Complex Content (§3.4.2.3.3),
Common Mapping Rules for Complex Type Definitions (§3.4.2.1),
Mapping Rule for Attribute Uses Property (§3.4.2.4),
and
Mapping Rule for Attribute Wildcard Property (§3.4.2.5).
For complex types with complex content, the {content type} property is calculated as follows. (For the {content type} on complex types with simple content, see Mapping Rules for Complex Types with Simple Content (§3.4.2.2).)
abc attribute is present
on the xyz element", if no xyz
element information item is present, then no
abc attribute is present on the
(non-existent) xyz element.false.minOccurs [attribute]
has the ·actual value· 0
and which has no [children] of its own
except for <annotation>;
maxOccurs
[attribute] with an ·actual value· of 0;true, then A particle whose properties are as
follows:
true, otherwise
element-onlytrue, otherwise
element-only
appliesToEmpty = true
mode = 'none'↑
, then
the ·explicit content type·.
mode =
'none'
, then
a Content Type as follows:
mode [attribute]
of the ·wildcard element·, if present,
otherwise interleave.
Any <complexType> source declaration can have <attribute> and <attributeGroup> elements as children, or descendants. The <attribute> element is described in XML Representation of Attribute Declaration Schema Components (§3.2.2) and will not be repeated here.
attributeGroup Element Information Item<attributeGroup
id = ID
ref = QName
{any attributes with non-schema namespace . . .}>
Content: (annotation?)
</attributeGroup>
The <attribute> and <attributeGroup> elements map to the {attribute uses} property of the Complex Type Definition component as described below. This mapping rule is the same for all complex type definitions.
If the
<schema> ancestor has a
defaultAttributes attribute, and the <complexType> element does not have
defaultAttributesApply =
false, then the {attribute uses}
property is
computed as if there were an
<attributeGroup> [child] with empty content
and a ref [attribute] whose ·actual value· is the
same as that of the
defaultAttributes
[attribute] appearing after any other
<attributeGroup>
[children]. Otherwise proceed as if there were no such
<attributeGroup> [child].
ref [attribute] of the <attributeGroup>
[children], if any.use =
prohibited.use attribute of an
<attribute> is in
establishing the correspondence between a complex type defined
by restriction and its XML representation. It serves to
prevent inheritance of an identically named attribute use from
the {base type definition}. Such an <attribute> does not correspond to any component, and
hence there is no interaction with either explicit or
inherited wildcards in the operation of Complex Type Definition Validation Rules (§3.4.4) or Constraints on Complex Type Definition Schema Components (§3.4.6).
It is pointless, though not an
error, for the use attribute to have the value
prohibited in other contexts (e.g. in complex type
extensions or named model group definitions), in which cases
the <attribute> element is simply ignored, provided that
it does not violate other constraints in this
specification.The {attribute wildcard} property of a Complex Type Definition depends on the <anyAttribute> element which may be present within the <complexType> element or within the attribute groups referred to within <complexType>. The <attributeGroup> element is described in the preceding section Mapping Rule for Attribute Uses Property (§3.4.2.4) and will not be repeated here.
If the <schema> ancestor has a
defaultAttributes attribute, and the
<complexType> element does not have
defaultAttributesApply = false, then the
{attribute wildcard} property is computed
as if there were an <attributeGroup>
[child] with empty content and a ref [attribute]
whose ·actual value· is the same as that of the
defaultAttributes [attribute] appearing after any
other <attributeGroup>
[children]. Otherwise proceed as if there were no such
<attributeGroup> [child].
The following declaration defines a type for specifications of length
by creating a complex type with simple content, with
xs:nonNegativeInteger as the type of the
content, and a unit attribute to give the
unit of measurement.
<xs:complexType name="length1"> <xs:simpleContent> <xs:extension base="xs:nonNegativeInteger"> <xs:attribute name="unit" type="xs:NMTOKEN"/> </xs:extension> </xs:simpleContent> </xs:complexType> <xs:element name="width" type="length1"/>
An instance using this type might look like this:
<width unit="cm">25</width>
A second approach to defining length uses two elements, one for size and one for the unit of measure. The definition of the type and the declaration of the element might look like this:
<xs:complexType name="length2">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="size" type="xs:nonNegativeInteger"/>
<xs:element name="unit" type="xs:NMTOKEN"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:element name="depth" type="length2"/>
An instance using this method might look like this:
<depth> <size>25</size><unit>cm</unit> </depth>
A third definition of type leaves the base type implicit; at the component level, the following declaration is equivalent to the preceding one.
<xs:complexType name="length3"> <xs:sequence> <xs:element name="size" type="xs:nonNegativeInteger"/> <xs:element name="unit" type="xs:NMTOKEN"/> </xs:sequence> </xs:complexType>
<xs:complexType name="personName">
<xs:sequence>
<xs:element name="title" minOccurs="0"/>
<xs:element name="forename" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="surname"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="extendedName">
<xs:complexContent>
<xs:extension base="personName">
<xs:sequence>
<xs:element name="generation" minOccurs="0"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="addressee" type="extendedName"/>
<addressee>
<forename>Albert</forename>
<forename>Arnold</forename>
<surname>Gore</surname>
<generation>Jr</generation>
</addressee><xs:complexType name="simpleName">
<xs:complexContent>
<xs:restriction base="personName">
<xs:sequence>
<xs:element name="forename" minOccurs="1" maxOccurs="1"/>
<xs:element name="surname"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:element name="who" type="simpleName"/>
<who>
<forename>Bill</forename>
<surname>Clinton</surname>
</who><xs:complexType name="paraType" mixed="true"> <xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:element ref="emph"/> <xs:element ref="strong"/> </xs:choice> <xs:attribute name="version" type="xs:decimal"/> </xs:complexType>
mixed attribute appearing on complexType itself.<xs:complexType name="name">
<xs:openContent>
<xs:any namespace="##other" processContents="skip"/>
</xs:openContent>
<xs:sequence>
<xs:element name="given" type="xs:string"/>
<xs:element name="middle" type="xs:string" minOccurs="0"/>
<xs:element name="family" type="xs:string"/>
</xs:sequence>
</xs:complexType><xs:complexType name="computer">
<xs:all>
<xs:element name="CPU" type="CPUType"/>
<xs:element name="memory" type="memoryType"/>
<xs:element name="monitor" type="monitorType"/>
<xs:element name="speaker" type="speakerType"
minOccurs="0"/>
<!-- Any additional information about the computer -->
<xs:any processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:all>
</xs:complexType>
<xs:complexType name="quietComputer">
<xs:complexContent>
<xs:restriction base="computer">
<xs:all>
<xs:element name="CPU" type="CPUType"/>
<xs:element name="memory" type="memoryType"/>
<xs:element name="monitor" type="monitorType"/>
<!-- Any additional information about the computer -->
<xs:any processContents="lax" notQName="speaker"
minOccurs="0" maxOccurs="unbounded"/>
</xs:all>
</xs:restriction>
</xs:complexContent>
</xs:complexType>quietComputer has
a lax wildcard, which ·matches· any element but one with the name
speaker.notQName attribute,
the wildcard would ·match· elements named
speaker, as well. In that case, the restriction
would be valid only if there is a
top-level declaration for speaker that also has type
speakerType or a type derived from it.
Otherwise, there would be instances locally valid against the restriction
quietComputer that are not locally valid against the base type
computer.notQName attribute on the wildcard and
no top-level declaration for speaker, then the following is allowed
by quietComputer, but not by computer:
<speaker xsi:type="xs:string"/>