W3C XML Schema Definition Language (XSD) 1.1 Part 1: Structures 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}
div.odiff-nsq-add { background-color: #DFDFDF; } div.odiff-nsq-del { display: none; background-color: #FFDFDF } div.idiff-nsq-del { display: none; text-decoration: line-through } div.odiff-nsq-chg { background-color: #DFDFDF } div.diff-nsq-off { }
span.odiff-nsq-add { background-color: #DFDFDF; } span.diff-nsq-add { background-color: #DFDFDF; } span.odiff-nsq-del { display: none; background-color: #FFDFDF } span.idiff-nsq-del { display: none; text-decoration: line-through } span.diff-nsq-del { display: none; background-color: #FFDFDF ; text-decoration: line-through } span.odiff-nsq-chg { background-color: #DFDFDF } span.diff-nsq-chg { background-color: #DFFFDF } span.diff-nsq-off { }
td.odiff-nsq-add { background-color: #DFDFDF; } td.odiff-nsq-del { display: none; background-color: #FFDFDF } td.odiff-nsq-chg { background-color: #DFDFDF } td.diff-nsq-off { }
table { width: 100%; } img { color: white; border: none } span.rfc2119 { font-variant: small-caps } span.nav { float: right} span.arrow { font-style: normal; font-weight: bold } span.enumval { font-style: italic; font-weight: bold }
code { font-family: monospace; font-size: 100%} span.propdef { font-weight: bold; font-family: monospace } span.termdef {color: #850021} div.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 } div.component {border: 2px solid black; margin-top: 1ex} span.propdef { font-weight: bold; font-family: monospace } div.ownDesc {margin-top: -2ex; margin-bottom: -2ex} a.compref {font-family: sans-serif; font-style: normal; color: black; text-decoration: none} 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.scHead { border: 4px double gray; border-bottom: 0px; text-align: center; margin-left: 1em; padding: .5em } 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.reprcompmulti, div.reprdep { border-top-width: 4px; border-top-style: double; border-top-color: #d3d3d3; padding: 4px ; margin: 0em} div.reprcomp {padding: 4px ; margin: 0em} div.reprHead { text-align: center; } div.mapSep { font-size: 50% ; clear: both} div.mapProp {clear: left; float: left; width: 5em; max-width: 12em; min-width: 5em } div.mapRepr { margin-left: 6.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.element-syntax-1 { font-family: monospace; margin: 0em; margin-top: 0em; margin-bottom: .5em } div.element-syntax { font-family: monospace; margin: 1em 0em; 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; margin-bottom: 0.6em; 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} 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 {margin: .5em; background-color: #f5dcb3} table.defset {background-color: #ffeedd } table.defset thead, table.diffed-defset thead { color: red; font-weight: bold } img { color: white; border: none } span.nav { float: right} span.arrow { font-style: normal; font-weight: bold } .shrink {font-size: 80% ; } .defset ul { margin-top: 0 ; margin-bottom: 0 ; } div.defset { margin: 4px ; border-width: 4px ; border-style: double ; border-color: gray ; } div.aux { background-color: #eeeeee ; color: #333333 ; } div.defset-head { font-weight: bold ; padding: 0.6em ; border-bottom-width: 4px ; border-bottom-style: double ; border-color: #cfcfcf ; } div.deftop {background-color: #d5dee3 ; margin-top: 1.5em; padding-bottom: 0.3em } div.defindent { margin-left: 1em ; margin-top: 0em ; margin-bottom: 0em ; } div.defargs { margin-left: 3em ; } div.prod { margin: 1em ; margin-left: 5em ; } .lhs { margin-left: -4em ; } table table, .defset table { margin: 0 ; border: 0 ; padding: 0 ; } .note { margin-left: 2em ; margin-top: 1em ; margin-bottom: 1em ; } div.issue { background-color: #d5bbbb} .giLabel, .pdName { margin-bottom: 0 ; font-weight: bold } .giDef, .pdDef { margin-left: 2.5em ; margin-top: 0}
dd > .giDef { margin-left: 0em; } dd > div.giDef > div.p { margin-left: 0em; margin-top: 0em; margin-bottom: 0em;}
div.pvlist { border: 4px double gray; margin-bottom: .5em; margin-left: 1em; padding: .5em; padding-right: 1em; padding-bottom: 1em } div.pvVal div.pvlist { border: 4px double gray; margin-top: 1.2em; margin-bottom: .5em; /* margin-left: -5em; */ margin-left: -1.3em; padding: .5em; padding-right: 1em; padding-bottom: 1em; } div.clnumber div.pvlist { border: 4px double gray; margin-bottom: .5em; margin-left: 1em; padding-top: .5em; text-indent: 0; padding-right: 1em; padding-bottom: 1em } div.mapRepr div.pvlist { border: 4px double gray; margin-top: .5em; margin-bottom: .5em; padding: .5em; padding-right: 1em; padding-bottom: 1em }
div.pvSep { font-size: 50% ; clear: both} div.pvProp {clear: left; float: left; width: 7em; max-width: 12em; min-width: 7em } div.pvVal { margin-left: 8em } div.pvpair { clear: both; padding: 0.3em; padding-right: 0; }
div.sfsScrap { border: 4px double gray; margin: 1em; padding: 0em; } div.sfsHead { margin: 4px; font-weight: bold } div.sfsBody { border-top-width: 4px; border-top-style: double; border-top-color: #d3d3d3; padding: 4px ; margin: 0em} div.ednote { display: block; margin: 1.33em 0; } a.scrapref { font-family: serif, sans-serif; }
/* Added 2008-01-30. Value may be tweaked, but whatever it is, * make it the same for these three different ways of saying * 'paragraph'. */ p, div.p, div.block { margin: 1em 0; } p.image-caption { margin-left: 2em; margin-right: 2em; margin-bottom: 3em; font-style: italic; }
var { /* color: green; */ color: navy; /* or perhaps try MediumBlue */ font-style: italic; font-weight: bold; }
table.blocknames, table.blocknames td, table.blocknames th { border-style: solid; border-width: thin; empty-cells: show; }
table.blocknames td, table.blocknames th { padding: 0.2em; } This version: http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/ Latest version: http://www.w3.org/TR/xmlschema11-1/ Previous version: http://www.w3.org/TR/2012/PR-xmlschema11-1-20120119/ Editors (Version 1.1): Shudi (Sandy) Gao 高殊镝, IBM <[email protected]> C. M. Sperberg-McQueen, Black Mesa Technologies LLC <[email protected]> Henry S. Thompson, University of Edinburgh <[email protected]> Editors (Version 1.0): Henry S. Thompson, University of Edinburgh <[email protected]> Noah Mendelsohn, IBM (retired) <[email protected]> David Beech, Oracle Corporation (retired) <[email protected]> Murray Maloney, Muzmo Communications <[email protected]> Please refer to the errata See also translations 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 List of translations Copyright W3C ® MIT ERCIM Keio liability trademark document use This document specifies the XML Schema Definition Language, which offers facilities for describing the structure and constraining the contents of XML documents, including those which exploit the XML Namespace facility. The schema language, which is itself represented in an XML vocabulary and uses namespaces, substantially reconstructs and considerably extends the capabilities found in XML document type definitions (DTDs). This specification depends on XML Schema Definition Language 1.1 Part 2: Datatypes 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 This W3C Recommendation specifies the W3C XML Schema Definition Language (XSD) 1.1. It is here made available for use 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 published on 5 April 2012. The major revisions since the previous public working draft include the following: Some minor errors, typographic and otherwise, have been corrected. For those primarily interested in the changes since version 1.0, the appendix Changes since version 1.0 (non-normative) (§G) 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 [email protected] archive This document has been reviewed by W3C Members, by software developers, and by other W3C groups and interested parties, and is endorsed by the Director as a W3C Recommendation. It is a stable document and may be used as reference material or cited from another document. 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. An implementation report The W3C XML Schema Working Group intends to process comments made about this recommendation, with any approved changes being handled as errata to be published separately. This document has been produced by the W3C XML Schema Working Group XML Activity Requirements for XML Schema 1.1 This document was produced by a group operating under the 5 February 2004 W3C Patent Policy public list of any patent disclosures Essential Claim(s) 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 1 Introduction Introduction to Version 1.1 Purpose Namespaces and Language Identifiers XSD Namespaces Namespaces with Special Status Conventional Namespace Bindings Schema Language Identifiers Dependencies on Other Specifications Documentation Conventions and Terminology Conceptual Framework Overview of XSD XSD Abstract Data Model Type Definition Components Declaration Components Model Group Components Constraint Components Group Definition Components Annotation Components Constraints and Validation Rules Conformance Schema-validity and documents Names and Symbol Spaces Schema-Related Markup in Documents Being Validated xsi:type xsi:nil xsi:schemaLocation, xsi:noNamespaceSchemaLocation Representation of Schemas on the World Wide Web Schema Component Details Introduction Attribute Declarations Element Declarations Complex Type Definitions Attribute Uses Attribute Group Definitions Model Group Definitions Model Groups Particles Wildcards Identity-constraint Definitions Type Alternatives Assertions Notation Declarations Annotations Simple Type Definitions Schemas as a Whole Schemas and Namespaces: Access and Composition Layer 1: Summary of the Schema-validity Assessment Core Layer 2: Schema Documents, Namespaces and Composition Basic concepts of schema construction and composition Conditional inclusion Assembling a schema for a single target namespace from multiple schema definition documents (<include>) Including modified component definitions (<redefine>) Overriding component definitions (<override>) References to schema components across namespaces (<import>) Layer 3: Schema Document Access and Web-interoperability Standards for representation of schemas and retrieval of schema documents on the Web How schema definitions are located on the Web Schemas and Schema-validity Assessment Errors in Schema Construction and Structure Assessing Schema-Validity Missing Sub-components Responsibilities of Schema-aware Processors A Schema for Schema Documents (Structures) (normative) Outcome Tabulations (normative) Validation Rules Contributions to the post-schema-validation infoset Schema Representation Constraints Schema Component Constraints Terminology for implementation-defined features (normative) Subset of the Post-schema-validation Infoset Terminology of schema construction Identifying locations where components are sought Identifying methods of indirection Identifying the key for use in indirection Identifying when to stop searching Identifying how to react to failure Other Implementation-defined Features Required Information Set Items and Properties (normative) Checklists of implementation-defined and implementation-dependent features (normative) Checklist of implementation-defined features Checklist of implementation-dependent features Stylesheets for Composing Schema Documents (Normative) Transformation for Chameleon Inclusion Transformation for xs:override Changes since version 1.0 (non-normative) Changes made since version 1.0 Relationship between XSD and other specifications XSD versions Changes to content models Assertions and XPath Derivation of complex types Changes to complex type definitions ID, IDREF, and related types Simple type definitions Element declarations Attribute declarations Component structure The process of validation The post-schema-validation infoset Conformance Schema composition Other substantive changes Clarifications and editorial changes Issues not resolved Glossary (non-normative) DTD for Schemas (non-normative) Analysis of the Unique Particle Attribution Constraint (non-normative) XSD Language Identifiers (non-normative) References Normative Non-normative Acknowledgements (non-normative) This document sets out the structural part of the XML Schema Definition Language. Chapter 2 presents a Conceptual Framework (§2) Chapter 3, Schema Component Details (§3) Chapter 4 presents Schemas and Namespaces: Access and Composition (§4) Chapter 5 discusses Schemas and Schema-validity Assessment (§5) The normative appendices include a Schema for Schema Documents (Structures) (normative) (§A) Normative (§L.1) The non-normative appendices include the DTD for Schemas (non-normative) (§I) Glossary (non-normative) (§H) This document is primarily intended as a language definition reference. As such, although it contains a few examples, it is not [XML Schema: Primer] The Working Group has three main goals for this version of W3C XML Schema: Significant improvements in simplicity of design and clarity of exposition without or Provision of support for versioning of XML languages defined using this specification, including the XML vocabulary specified here for use in schema documents. Provision of support for co-occurrence constraints, that is constraints which make the presence of an attribute or element, or the values allowable for it, depend on the value or presence of other attributes or elements. These goals are in tension with one another. The Working Group's strategic guidelines for changes between versions 1.0 and 1.1 can be summarized as follows: Support for versioning (acknowledging that this may Support for co-occurrence constraints (which will certainly involve additions to the XML transfer syntax, which will not be understood by 1.0 processors) Bug fixes (unless in specific cases we decide that the fix is too disruptive for a point release) Editorial changes Design cleanup will possibly change behavior in edge cases Non-disruptive changes to type hierarchy (to better support current and forthcoming international standards and W3C recommendations) Design cleanup will possibly change component structure (changes to functionality restricted to edge cases) No significant changes in existing functionality No changes to XML transfer syntax except those required by version control hooks, co-occurrence constraints and bug fixes The aim with regard to compatibility is that All schema documents conformant to version 1.0 of this specification [XSD 1.0 2E] · · The vast majority of schema documents conformant to version 1.1 of this specification should also conform to version 1.0, leaving aside any incompatibilities arising from support for versioning or co-occurrence constraints, and when they are conformant to version 1.0 (or are made conformant by the removal of versioning information), should have the same · · The purpose of XML Schema Definition Language: Structures The purpose of an XSD schema is to define and describe a class of XML documents by using schema components to constrain and document the meaning, usage and relationships of their constituent parts: datatypes, elements and their content and attributes and their values. Schemas can also provide for the specification of additional document information, such as normalization and defaulting of attribute and element values. Schemas have facilities for self-documentation. Thus, XML Schema Definition Language: Structures Any application that consumes well-formed XML can use the formalism defined here to express syntactic, structural and value constraints applicable to its document instances. The XSD formalism allows a useful level of constraint checking to be described and implemented for a wide spectrum of XML applications. However, the language defined by this specification does not attempt to provide all 1.3.1 XSD Namespaces The Schema Namespace (xs) The Schema Instance Namespace (xsi) The Schema Versioning Namespace (vc) Namespaces with Special Status Conventional Namespace Bindings Schema Language Identifiers xs The XML representation of schema components uses a vocabulary identified by the namespace name http://www.w3.org/2001/XMLSchema xs: Note: [XSD 1.0 2E] · · Note: [XPath 2.0] [XDM] untyped untypedAtomic [XDM] Users of the namespaces defined here should be aware, as a matter of namespace policy, that more names in this namespace may be given definitions in future versions of this or other specifications. xsi This specification defines several attributes for direct use in any XML documents, as described in Schema-Related Markup in Documents Being Validated (§2.7) http://www.w3.org/2001/XMLSchema-instance xsi: Users of the namespaces defined here should be aware, as a matter of namespace policy, that more names in this namespace may be given definitions in future versions of this or other specifications. vc The pre-processing of schema documents described in Conditional inclusion (§4.2.2) http://www.w3.org/2007/XMLSchema-versioning vc: Users of the namespaces defined here should be aware, as a matter of namespace policy, that more names in this namespace may be given definitions in future versions of this or other specifications. Except as otherwise specified elsewhere in this specification, if components are · · should · · http://www.w3.org/XML/1998/namespace http://www.w3.org/2001/XMLSchema http://www.w3.org/2001/XMLSchema-instance http://www.w3.org/2007/XMLSchema-versioning Note: This flexibility does not extend to the components described in this specification or in [XML Schema: Datatypes] expanded names expanded names Components and source declarations must not http://www.w3.org/2000/xmlns/ · · Note: Several namespace prefixes are conventionally used in this document for notational convenience. The following bindings are assumed. fn http://www.w3.org/2005/xpath-functions [Functions and Operators] html http://www.w3.org/1999/xhtml my rddl http://www.rddl.org/ vc http://www.w3.org/2007/XMLSchema-versioning xhtml http://www.w3.org/1999/xhtml xlink http://www.w3.org/1999/xlink xml http://www.w3.org/XML/1998/namespace [XML 1.1] [XML Namespaces 1.1] xs http://www.w3.org/2001/XMLSchema xsi http://www.w3.org/2001/XMLSchema-instance xsl http://www.w3.org/1999/XSL/Transform In practice, any prefix bound to the appropriate namespace name may xml xmlns Sometimes other specifications or Application Programming Interfaces (APIs) need to refer to the XML Schema Definition Language in general, sometimes they need to refer to a specific version of the language, possibly even to a version defined in a superseded draft. To make such references easy and enable consistent identifiers to be used, we provide the following URIs to identify these concepts. http://www.w3.org/XML/XMLSchema Identifies the XML Schema Definition Language in general, without referring to a specific version of it. http://www.w3.org/XML/XMLSchema/v X Y Identifies the language described in version X Y http://www.w3.org/XML/XMLSchema/v1.0 http://www.w3.org/XML/XMLSchema/v1.1 http://www.w3.org/XML/XMLSchema/v X Y N Identifies the language described in the N X Y http://www.w3.org/XML/XMLSchema/v1.0/2e http://www.w3.org/XML/XMLSchema/v X Y N Identifies the language described in the N X Y yyyy-mm-dd http://www.w3.org/XML/XMLSchema/v1.0/1e/20001024 http://www.w3.org/XML/XMLSchema/v1.0/2e/20040318 Please see XSD Language Identifiers (non-normative) (§K) The definition of XML Schema Definition Language: Structures [XML Infoset] [XML Namespaces 1.1] [XPath 2.0] [XML Schema: Datatypes] See Required Information Set Items and Properties (normative) (§D) [XML Infoset] [XML Schema: Datatypes] [XML 1.1] [XML Namespaces 1.1] [XML 1.0] [Namespaces in XML 1.0] [XML 1.1] [XML Namespaces 1.1] · · · · Conforming implementations of this specification may should Note: may should Note: may may The section introduces the highlighting and typography as used in this document to present technical material. Unless otherwise noted, the entire text of this specification is normative. Exceptions include: notes sections explicitly marked non-normative examples and their commentary informal descriptions of the consequences of rules formally and normatively stated elsewhere (such informal descriptions are typically introduced by phrases like "Informally, ..." or "It is a consequence of ... that ...") Special terms are defined at their point of introduction in the text. For example [Definition:] term · · Non-normative examples are set off in boxes and accompanied by a brief explanation: Example <schema targetNamespace="http://www.example.com/XMLSchema/1.0/mySchema"> And an explanation of the example. The definition of each kind of schema component consists of a list of its properties and their contents, followed by descriptions of the semantics of the properties: Schema Component: Example {example property} A Component An example property References to properties of schema components are links to the relevant definition as exemplified above, set off with curly braces, for instance {example property} For a given component C C {example property} {example property} C C C {p1} {p2} C {p1} {p2} {p2} · · C {p1} For components C 1 C 2 C 1 {example property 1} C 2 {example property 2} C 1 C 2 C 1 C 2 C 1 C 2 C 1 {example property} C 2 C 2 C 1 {example property} The correspondence between an element information item which is part of the XML representation of a schema and one or more schema components is presented in a tableau which illustrates the element information item(s) involved. This is followed by a tabulation of the correspondence between properties of the component and properties of the information item. Where context determines which of several different components corresponds to the source declaration, several tabulations, one per context, are given. The property correspondences are normative, as are the illustrations of the XML representation element information items. In the XML representation, bold-face attribute names (e.g. count size [XML Schema: Datatypes] The allowed content of the information item is shown as a grammar fragment, using the Kleene operators ? * + Note: Schema for Schema Documents (Structures) (normative) (§A) Schema for Schema Documents (Structures) (normative) (§A) · · XML Representation Summary example <example count integer large medium small Content: all any Example Schema Component Property Representation {example property} Description of what the property corresponds to, e.g. the value of the size [attribute] References to elements in the text are links to the relevant illustration as exemplified above, set off with angle brackets, for instance <example> Unless otherwise specified, references to attribute values are references to the · · · · E E att1 V att1 [attributes] E · · V E att1 V att1 V · · att1 not V References to properties of information items as defined in [XML Infoset] [children] Properties which this specification defines for information items are introduced as follows: PSVI Contributions for [new property] The value the property gets. References to properties of information items defined in this specification are notated as links to their introduction as exemplified above, set off with square brackets, for example [new property] The "dot operator" described above for components and their properties is also used for information items and their properties. For a given information item I I [new property] [new property] I Lists of normative constraints are typically introduced with phrase like "all of the following are true" (or "... apply"), "one of the following is true", "at least one of the following is true", "one or more of the following is true", "the appropriate case among the following is true", etc. The phrase "one of the following is true" is used in cases where the authors believe the items listed to be mutually exclusive (so that the distinction between "exactly one" and "one or more" does not arise). If the items in such a list are not in fact mutually exclusive, the phrase "one of the following" should be interpreted as meaning "one or more of the following". The phrase "the appropriate case among the following" is used only when the cases are thought by the authors to be mutually exclusive; if the cases in such a list are not in fact mutually exclusive, the first applicable case should be taken. Once a case has been encountered with a true condition, subsequent cases must The following highlighting is used for non-normative commentary in this document: Note: Within normative prose in this specification, the words may should must must not may Schemas, schema documents, and processors are permitted to but need not behave as described. should It is recommended that schemas, schema documents, and processors behave as described, but there can be valid reasons for them not to; it is important that the full implications be understood and carefully weighed before adopting behavior at variance with the recommendation. must (Of schemas and schema documents:) · · (Of processors:) must not Schemas, schema documents, and processors are forbidden to behave as described; schemas and documents which nevertheless do so are in · · A failure of a schema or schema document to conform to the rules of this specification. Except as otherwise specified, processors must · · · · must · · Outcome Tabulations (normative) (§B) · · Note: Note: [schema error code] [schema error code] are A feature or construct defined in this specification described as deprecated should Deprecation has no effect on the conformance of schemas or schema documents which use deprecated features. Since deprecated features are part of the specification, processors must may Features deprecated in this version of this specification may be removed entirely in future versions, if any. [Definition:] user option A choice left under the control of the user of a processor, rather than being fixed for all users or uses of the processor. Statements in this specification that "Processors may may must not must Note: Note: These definitions describe in terms specific to this document the meanings assigned to these terms by [IETF RFC 2119] [XML 1.1] Where these terms appear without special highlighting, they are used in their ordinary senses and do not express conformance requirements. Where these terms appear highlighted within non-normative material (e.g. notes), they are recapitulating rules normatively stated elsewhere. This specification provides a further description of error and of conformant processors' responsibilities with respect to errors in Schemas and Schema-validity Assessment (§5) This chapter gives an overview of XML Schema Definition Language: Structures Schema Component Details (§3) [XML Schema: Primer] Schema Component Details (§3) XML Representation of ... An XSD schema is a set of components such as type definitions and element declarations. These can be used to assess the validity of well-formed element and attribute information items (as defined in [XML Infoset] [Definition:] post-schema-validation infoset PSVI may Subset of the Post-schema-validation Infoset (§C.1) [Definition:] schema-validity assessment 1 Determining local schema-validity, that is whether an element or attribute information item satisfies the constraints embodied in the relevant components of an XSD schema (specifically the · · · · 2 Determining an overall validation outcome for the item by combining local schema-validity with the results of schema-validity assessments of its descendants, if any; and 3 Determining the appropriate augmentations to the infoset (and, if desired, exposing them to downstream applications in some way, to record this outcome). Throughout this specification, [Definition:] assessment · · [Definition:] Validation [validity] Note: · · [validity] notKnown notKnown invalid Note: · · valid In general, a valid document against a particular schema · · Schema-validity and documents (§2.5) Because the [validity] property is part of the · · · · · · · · · · · · · · · · · · · · Note: · · · · · · · · During · · · · [Definition:] · · govern governing governing Note: · · · · · · · · 2.2.1 Type Definition Components Type Definition Hierarchy Simple Type Definition Complex Type Definition Declaration Components Element Declaration Element Substitution Group Attribute Declaration Notation Declaration Model Group Components Model Group Particle Attribute Use Wildcard Constraint Components Identity-constraint Definition Type Alternative Assertion Overlapping Functionality of Constraint Components Group Definition Components Model Group Definition Attribute Group Definition Annotation Components This specification builds on [XML 1.1] [XML Namespaces 1.1] information items [XML Infoset] a priori well-formedness [XML 1.1] namespace conformance [XML Namespaces 1.1] · · · · Just as [XML 1.1] [XML Namespaces 1.1] must [Definition:] Schema component [Definition:] XSD schema · · may must Simple type definitions Complex type definitions Attribute declarations Element declarations The secondary schema components, are as follows: Attribute group definitions Identity-constraint definitions Type alternatives Assertions Model group definitions Notation declarations Finally, the "helper" schema components provide small parts of other schema components; they are dependent on their context: Annotations Model groups Particles Wildcards Attribute Uses The name [Definition:] Component During · · [Definition:] declaration · · On the other hand, [Definition:] definition [Definition:] may must name [XML Namespaces 1.1] [Definition:] target namespace · · [XML Namespaces 1.1] · · An expanded name [XML Namespaces 1.1] may · · expanded name · · · · expanded name · · Note: · · · · · · · · Schema Component Details (§3) · · · · The abstract model provides two kinds of type definition component: simple and complex. [Definition:] type definition Type definitions form a hierarchy with a single root. The subsections below first describe characteristics of that hierarchy, then provide an introduction to simple and complex type definitions themselves. [Definition:] · xs:anyType · · · · · · · · xs:anyType · · · · xs:anyType · Type Definition Hierarchy · xs:anyType · [Definition:] · · · · base type definition [Definition:] D B D derived B · xs:anyType · [Definition:] · · restriction A B A · · B A B [Definition:] extension Note: · · · · T · · T · · T T T [Definition:] anyType · · definition of anyType [Definition:] error · · XSD error For brevity, the text and examples in this specification often use the qualified names xs:anyType xs:error Schema-Related Markup in Documents Being Validated (§2.7) A simple type definition is a set of constraints on strings and information about the values they encode, applicable to the · · Each simple type definition, whether built-in (that is, defined in [XML Schema: Datatypes] · · · · [Definition:] · · · xs:anyType · anySimpleType · · · xs:anySimpleType · atomic values atomic values · xs:anyType · xs:anySimpleType · xs:anySimpleType · · · [Definition:] anyAtomicType · · · xs:anySimpleType · · · xs:anyAtomicType [Definition:] constructed restricting {base type definition} Constraining Facet list {item type definition} union {member type definitions} The mapping from lexical space to value space is unspecified for items whose type definition is · xs:anySimpleType · · xs:anyAtomicType · · xs:anySimpleType · · xs:anyAtomicType · Note: [XML Schema: Datatypes] · · · · · xs:anySimpleType · For detailed information on simple type definitions, see Simple Type Definitions (§3.16) [XML Schema: Datatypes] A complex type definition is a set of attribute declarations and a content type, applicable to the [attributes] [children] may [children] Each complex type definition other than · xs:anyType · a restriction of a complex · · an · · · · A complex type which extends another does so by having additional content model particles at the end of the other definition's content model, or by having additional attribute declarations, or both. Note: all Open Content interleave For detailed information on complex type definitions, see Complex Type Definitions (§3.4) There are three kinds of declaration component: element, attribute, and notation. Each is described in a section below. Also included is a discussion of element substitution groups, which is a feature provided in conjunction with element declarations. An element declaration is an association of a name with a type definition, either simple or complex, an (optional) default value and a (possibly empty) set of identity-constraint definitions. The association is either global or scoped to a containing complex type definition. A top-level element declaration with name 'A' is broadly comparable to a pair of DTD declarations as follows, where the associated type definition fills in the ellipses: <!ELEMENT A . . .> <!ATTLIST A . . .> Element declarations contribute to · · · · · · For detailed information on element declarations, see Element Declarations (§3.3) Identity-constraint Definition (§2.2.4.1) When XML vocabularies are defined using the DTD syntax defined by [XML 1.1] element type declaration Note: [XML 1.1] · · [XML 1.1] [XML 1.1] [Definition:] element substitution groups · · · · · · · · All such members must · · · · Note that element substitution groups are not represented as separate components. They are specified in the property values for element declarations (see Element Declarations (§3.3) An attribute declaration is an association between a name and a simple type definition, together with occurrence information and (optionally) a default value. The association is either global, or local to its containing complex type definition. Attribute declarations contribute to · · · · For detailed information on attribute declarations, see Attribute Declarations (§3.2) A notation declaration is an association between a name and an identifier for a notation. For an attribute or element information item to be · · NOTATION must For detailed information on notation declarations, see Notation Declarations (§3.14) The model group, particle, and wildcard components contribute to the portion of a complex type definition that controls an element information item's content. A model group is a constraint in the form of a grammar fragment that applies to lists of element information items. It consists of a list of particles, i.e. element declarations, wildcards and model groups. There are three varieties of model group: Sequence (the element information items match the particles in sequential order); Conjunction (the element information items match the particles, in any order); Disjunction (the element information items match one or more of the particles). Each model group denotes a set of sequences of element information items. Regarding that set of sequences as a language, the set of sequences recognized by a group G L G [Definition:] G accept recognize L G For detailed information on model groups, see Model Groups (§3.8) A particle is a term in the grammar for element content, consisting of either an element declaration, a wildcard or a model group, together with occurrence constraints. Particles contribute to · · · · The name [Definition:] Term · · · · [Definition:] basic term Element Declaration Wildcard [Definition:] basic particle Particle {term} · · [Definition:] · · [children] content model Note: · · [XML 1.1] [XML 1.1] · · Each content model, indeed each particle and each term, denotes a set of sequences of element information items. Regarding that set of sequences as a language, the set of sequences recognized by a particle P L P [Definition:] P accept recognize L P T accepts recognizes L T Note: L P P Principles of Validation against Groups (§3.8.4.2) No assumption is made, in the definition above, that the items in the sequence are themselves valid; only the expanded names If a sequence S L P · · P S P P S · · S P Note: · · · · · · S P For detailed information on particles, see Particles (§3.9) An attribute use plays a role similar to that of a particle, but for attribute declarations: an attribute declaration used by a complex type definition is embedded within an attribute use, which specifies whether the declaration requires or merely allows its attribute, and whether it has a default or fixed value. A wildcard is a special kind of particle which matches element and attribute information items dependent on their namespace names and optionally on their local names. For detailed information on wildcards, see Wildcards (§3.10) This section describes constructs which use [XPath 2.0] An identity-constraint definition is an association between a name and one of several varieties of identity-constraint related to uniqueness and reference. All the varieties use [XPath 2.0] · · · · For detailed information on identity-constraint definitions, see Identity-constraint Definitions (§3.11) Note: [XSD 1.0 2E] [XPath 1.0] [XPath 2.0] A Type Alternative · · {type table} · · Note: [SchemaPath] For detailed information on Type Alternatives, see Type Alternatives (§3.12) An assertion is a predicate associated with a type, which is checked for each instance of the type. If an element or attribute information item fails to satisfy an assertion associated with a given type, then that information item is not locally · · For detailed information on Assertions, see Assertions (§3.13) Many rules that can be enforced by identity constraints and conditional type assignment can also be formulated in terms of assertions. That is, the various constructs have overlapping functionality. The three forms of constraint differ from each other in various ways which may affect the schema author's choice of formulation. Most obviously, the · · Less obviously, identity constraints are associated with element declarations, while assertions are associated with type definitions. If it is desired to enforce a particular property of uniqueness or referential integrity associated with a particular element declaration E T E T E T E E E T T E E Similar considerations sometimes apply to the choice between assertions and conditional type assignment. Because identity constraints and conditional type assignment are simpler and less variable than assertions, it may be easier for software to exploit or optimize them. Assertions have greater expressive power, which means they are often convenient. The "rule of least power" applies here; it is often preferable to use a less expressive notation in preference to a more expressive one, when either will suffice. See [Rule of Least Power] There are two kinds of convenience definitions provided to enable the re-use of pieces of complex type definitions: model group definitions and attribute group definitions. A model group definition is an association between a name and a model group, enabling re-use of the same model group in several complex type definitions. For detailed information on model group definitions, see Model Group Definitions (§3.7) An attribute group definition is an association between a name and a set of attribute declarations, enabling re-use of the same set in several complex type definitions. For detailed information on attribute group definitions, see Attribute Group Definitions (§3.6) An annotation is information for human and/or mechanical consumers. The interpretation of such information is not defined in this specification. For detailed information on annotations, see Annotations (§3.15) The [XML 1.1] well-formedness validity The preceding section focused on · · · · Schema Component Constraint [Definition:] must Schema Component Details (§3) Schema Component Constraints (§B.4) Schema Representation Constraint [Definition:] Schema for Schema Documents (Structures) (normative) (§A) Schema Component Details (§3) Schema Representation Constraints (§B.3) Validation Rules [Definition:] · · Schema Component Details (§3) Validation Rules (§B.1) Schema Information Set Contribution [Definition:] · · · · Schema Component Details (§3) Contributions to the post-schema-validation infoset (§B.2) The last of these, schema information set contributions, are not as new as they might at first seem. XML validation augments the XML information set in similar ways, for example by providing values for attributes not present in instances, and by implicitly exploiting type information for normalization or access. (As an example of the latter case, consider the effect of NMTOKENS ID IDREF Note: Within the context of this specification, conformance can be claimed for schema documents, for schemas, and for processors. A · · all 1 It is valid with respect to the top-level element declaration for <schema> Schema for Schema Documents (Structures) (normative) (§A) · · · · <schema> · · <schema> [validation attempted] full partial [validity] valid 2 No element in the schema document violates any of the Schema Representation Constraints set out in Schema Representation Constraints (§B.3) <annotation> Note: <annotation> If the schema document is invalid only in consequence of invalid descendants of <annotation> may · · <annotation> Note: expanded name Note: A schema conforms to this specification if and only if it consists of components which individually and collectively satisfy all the relevant constraints specified in this document, including but not limited to all the · · Note: This specification distinguishes several classes of conforming processors, which are defined in terms of the following concepts. [Definition:] validator instance validator · · · · · · · · Schema-validity and documents (§2.5) may · · [Definition:] schema-validity assessor assessor · · · · · · · · · · [Definition:] general-purpose · · · · Layer 2: Schema Documents, Namespaces and Composition (§4.2) Note: · · · · Conditional inclusion (§4.2.2) · · Assembling a schema for a single target namespace from multiple schema definition documents ( <include> [Definition:] · · special-purpose Note: · · · · · · [Definition:] Web-aware · · must Representation of Schemas on the World Wide Web (§2.8) How schema definitions are located on the Web (§4.3.2) Note: · · · · Several important classes of processor can be defined in terms of the concepts just given: · · · · · · · · · · · · · · Note: Processors (other than those otherwise defined) which perform some task, service, or activity which depends at least in part on the contents of some schema, and which do so in ways which are consistent with the provisions of this specification. Note: · · A claim that a processor conforms to this specification must Note: See Checklist of implementation-defined features (§E.1) Terminology for implementation-defined features (normative) (§C) As noted above, in general a document is valid against a particular schema Note: The terms defined capture some commonly used requirements, but the specification of which documents should be regarded as acceptable for a specific application, or as conforming to a given specification, is out of scope for this specification. Applications and specifications which use XSD are free to specify whatever constraints they see fit on documents; the provision of terms for the concepts identified here should not be taken to imply that other rules for document acceptability are discouraged or inappropriate. All the terms defined below require that the document's root element be · · · · · · A document is root-valid · · [validity] valid [validation attempted] full partial A document is deep-valid · · all 1 The document's root element has [validity] valid 2 The document's root element has [validation attempted] full partial 3 No element in the document has [validity] invalid 4 No attribute in the document has [validity] invalid Note: [validity] invalid A document is uniformly valid · · all 1 The document's root element has [validity] valid 2 The document's root element has [validation attempted] full Note: Assessment Outcome (Element) (§3.3.5.1) [validation attempted] It follows from the first and second clauses that every element and attribute in the document has been · · uniform validity deep validity notKnown · · · · Note: [schema error code] · · [validity] notKnown [schema error code] [validity] notKnown [validity] valid [validity] notKnown · · As discussed in XSD Abstract Data Model (§2.2) may · · · · Therefore [Definition:] symbol space XSD Abstract Data Model (§2.2) must expanded name expanded name may my my:abc my:abc Locally scoped attribute and element declarations are special with regard to symbol spaces. Their names are not included in the global symbol spaces for attribute and element names; each complex type definition defines its own attribute symbol space, and elements local to a complex type definition are constrained by Element Declarations Consistent (§3.8.6.3) 2.7.1 xsi:type xsi:nil xsi:schemaLocation, xsi:noNamespaceSchemaLocation XML Schema Definition Language: Structures http://www.w3.org/2001/XMLSchema-instance The Schema Instance Namespace ( xsi must Attribute Declaration for the 'type' attribute (§3.2.7.1) Attribute Declaration for the 'nil' attribute (§3.2.7.2) Attribute Declaration for the 'schemaLocation' attribute (§3.2.7.3) Attribute Declaration for the 'noNamespaceSchemaLocation' attribute (§3.2.7.4) Note: Conventional Namespace Bindings (§1.3.3) xsi:type xsi:nil [namespace name] http://www.w3.org/2001/XMLSchema-instance [local name] type nil The Simple Type Definition (§2.2.1.2) Complex Type Definition (§2.2.1.3) · · may xsi:type · · QName resolution (Instance) (§3.17.6.3) · · XML Schema Definition Language: Structures must · · · · xsi:nil true must The xsi:schemaLocation xsi:noNamespaceSchemaLocation · · How schema definitions are located on the Web (§4.3.2) Note: xsi:schemaLocation · · schemaLocation On the World Wide Web, schemas are conventionally represented as XML documents (preferably of MIME type application/xml text/xml 1.1 Inclusion Constraints and Semantics (§4.2.3) Layer 2: Schema Documents, Namespaces and Composition (§4.2) Standards for representation of schemas and retrieval of schema documents on the Web (§4.3.1) How schema definitions are located on the Web (§4.3.2) 3.1.1 Components and Properties XML Representations of Components The Mapping between XML Representations and Components White Space Normalization during Validation The following sections provide full details on the composition of all schema components, together with their XML representations and their contributions to · · properties: their values and significance XML representation and the mapping to properties constraints on representation validation rules · · constraints on the components themselves Components are defined in terms of their properties, and each property in turn is defined by giving its range, that is the values it may not · · must not Note: Component properties are simply named values. Most properties have either other components or literals (that is, strings or booleans or enumerated keywords) for values, but in a few cases, where more complex values are involved, [Definition:] property record [Definition:] absent null [Definition:] · · present Any property not defined as optional is always present; optional properties which are not present are taken to have · · not · · legal XML characters [XML 1.1] Note: · · [XML 1.1] [XML 1.0] The principal purpose of XML Schema Definition Language: Structures [Definition:] <schema> schema document Schema for Schema Documents (Structures) (normative) (§A) DTD for Schemas (non-normative) (§I) [namespace name] http://www.w3.org/2001/XMLSchema · · [XML Infoset] Two aspects of the XML representations of components presented in the following sections are constant across them all: All of them allow attributes qualified with namespace names other than the XSD namespace itself: these appear as annotations in the corresponding schema component; All of them allow an <annotation> A recurrent pattern in the XML representation of schemas may also be mentioned here. In many cases, the same element name (e.g. element attribute attributeGroup name ref The descriptions of the XML representation of components, and the · · after · · Conditional inclusion (§4.2.2) · · Assembling a schema for a single target namespace from multiple schema definition documents ( <include> For each kind of schema component there is a corresponding normative XML representation. The sections below describe the correspondences between the properties of each kind of schema component on the one hand and the properties of information items in that XML representation on the other, together with constraints on that representation above and beyond those expressed in the Schema for Schema Documents (Structures) (normative) (§A) <appinfo> <documentation> The language used is as if the correspondences were mappings from XML representation to schema component, but the mapping in the other direction, and therefore the correspondence in the abstract, can always be constructed therefrom. In discussing the mapping from XML representations to schema components below, the value of a component property is often determined by the value of an attribute information item, one of the [attributes] Schema for Schema Documents (Structures) (normative) (§A) [Definition:] actual value lexical mapping · · enumeration · · · · Many properties are identified below as having other schema components or sets of components as values. For the purposes of exposition, the definitions in this section assume that (unless the property is explicitly identified as optional) all such values are in fact present. When schema components are constructed from XML representations involving reference by name to other components, this assumption will in some cases be violated if one or more references cannot be · · Missing Sub-components (§5.3) Forward reference to named definitions and declarations is · · · · Schemas and Namespaces: Access and Composition (§4) Throughout this specification, [Definition:] initial value [normalized value] initial value [character code] [children] The above definition means that comments and processing instructions, even in the midst of text, are ignored for most · · Assertion Satisfied (§3.13.4.1) [Definition:] normalized value · · whiteSpace facet pre-lexical facets · · preserve No normalization is done, the whitespace-normalized value is the · · replace All occurrences of #x9 #xA #xD #x20 collapse Subsequent to the replacements specified above under replace #x20 #x20 #x20 normalized value whiteSpace facet pre-lexical facets When more than one pre-lexical facet whiteSpace facet · · · · If the simple type definition used in an item's · · · xs:anySimpleType · · · must preserve There are three alternative validation rules which help supply the necessary background for the above: Attribute Locally Valid (§3.2.4.1) 3 Element Locally Valid (Type) (§3.3.4.4) 3.1.3 Element Locally Valid (Complex Type) (§3.4.4.2) 1.2 These three levels of normalization correspond to the processing mandated in XML for element content, CDATA attribute content and tokenized attributed content, respectively. See Attribute Value Normalization [XML 1.1] replace collapse · · [normalized value] Note: has Attribute Value Normalization further · · Note: replace collapse 3.2.1 The Attribute Declaration Schema Component XML Representation of Attribute Declaration Schema Components Mapping Rules for Global Attribute Declarations Mapping Rules for Local Attribute Declarations Mapping Rules for References to Top-level Attribute Declarations Constraints on XML Representations of Attribute Declarations Attribute Declaration Validation Rules Attribute Locally Valid Governing Attribute Declaration and Governing Type Definition Schema-Validity Assessment (Attribute) Attribute Declaration Information Set Contributions Assessment Outcome (Attribute) Validation Failure (Attribute) Attribute Declaration Attribute Validated by Type Constraints on Attribute Declaration Schema Components Attribute Declaration Properties Correct Simple Default Valid xmlns Not Allowed xsi: Not Allowed Built-in Attribute Declarations xsi:type xsi:nil xsi:schemaLocation xsi:noNamespaceSchemaLocation Attribute declarations provide for: Local · · Specifying default or fixed values for attribute information items. Example <xs:attribute name="age" type="xs:positiveInteger" use="required"/> The XML representation of an attribute declaration. The attribute declaration schema component has the following properties: Schema Component: Attribute Declaration Annotated Component {annotations} A sequence of Annotation {name} An xs:NCName value. Required. {target namespace} An xs:anyURI value. Optional. {type definition} A Simple Type Definition {scope} A Scope {value constraint} A Value Constraint {inheritable} An xs:boolean value. Required. Property Record: Scope {variety} One of { global local {parent} Either a Complex Type Definition Attribute Group Definition {variety} local must · · Property Record: Value Constraint {variety} One of { default fixed {value} An · · {lexical form} A character string. Required. The {name} must · · The value of each attribute validated must {type definition} A · · {target namespace} · · must · · {target namespace} · · For an attribute declaration A A {scope} {variety} global A A {scope} {variety} local A Complex Type Definition Attribute Group Definition A {scope} {parent} The {value constraint} #FIXED {variety} default · · {value} {lexical form} fixed must {value} {value} {lexical form} default values See Annotations (§3.15) {annotations} Note: {name} {target namespace} {value constraint} · · Element Locally Valid (Complex Type) (§3.4.4.2) [XML Infoset] xmlns xmlns:xsl [namespace attributes] xmlns The XML representation for an attribute declaration schema component is an <attribute> may · · Attribute declarations can appear at the top level of a schema document, or within complex type definitions, either as complete (local) declarations, or by reference to top-level declarations, or within attribute group definitions. For complete declarations, top-level or local, the type <simpleType> · xs:anySimpleType · XML Representation Summary attribute <attribute string string qualified unqualified ID NCName QName anyURI QName optional prohibited required boolean {any attributes with non-schema namespace . . .} Content: annotation simpleType An <attribute> Top-level <attribute> <schema> global <attribute> <attributeGroup> <complexType> global ref type <simpleType> Note: <override> · · Overriding component definitions ( <override> Attribute information items · · must {target namespace} {target namespace} · · must · · must form [attribute] attributeFormDefault [attribute] <schema> {target namespace} The names for top-level attribute declarations are in their own · · The following sections specify several sets of XML mapping rules which apply in different circumstances. If the <attribute> <schema> Attribute Declaration Mapping Rules for Global Attribute Declarations (§3.2.2.1) If the <attribute> <complexType> <attributeGroup> ref [attribute] use [attribute] "prohibited" Attribute Declaration Attribute Use Mapping Rules for Local Attribute Declarations (§3.2.2.2) On Attribute Use Attribute Uses (§3.5) If the <attribute> <complexType> <attributeGroup> ref [attribute] · · use [attribute] "prohibited" Attribute Use Mapping Rules for References to Top-level Attribute Declarations (§3.2.2.3) If the <attribute> use='prohibited' Note: use <attribute> <attribute> <complexType> <attributeGroup> If the <attribute> <schema> XML Mapping Summary for Attribute Declaration Schema Component Property Representation {name} The · · name [attribute] {target namespace} The · · targetNamespace [attribute] <schema> · · {type definition} The simple type definition corresponding to the <simpleType> [children] · · · · type [attribute] · xs:anySimpleType · {scope} A Scope Property Value {variety} global {parent} · · {value constraint} If there is a default fixed [attribute] Value Constraint · · Property Value {variety} either default fixed {value} the · · {type definition} [attribute] {lexical form} the · · {type definition} [attribute] {inheritable} The · · inheritable [attribute] false {annotations} The · · <attribute> XML Representation of Annotation Schema Components (§3.15.2) If the <attribute> <complexType> <attributeGroup> ref [attribute] below use='prohibited' XML Mapping Summary for Attribute Use Schema Component Property Representation {required} true <attribute> use required false {attribute declaration} See the Attribute Declaration mapping immediately below. {value constraint} If there is a default fixed [attribute] Value Constraint · · Property Value {variety} either default fixed {value} the · · [attribute] {attribute declaration} {type definition} {lexical form} the · · [attribute] {attribute declaration} {type definition} {inheritable} The · · inheritable [attribute] false {annotations} The same annotations as the {annotations} <attribute> {attribute declaration} XML Mapping Summary for Attribute Declaration Schema Component Property Representation {name} The · · name [attribute] {target namespace} The appropriate case 1 If targetNamespace then · · 2 If targetNamespace one 2.1 form qualified 2.2 form <schema> attributeFormDefault qualified then · · targetNamespace [attribute] <schema> · · 3 otherwise · · {type definition} The simple type definition corresponding to the <simpleType> [children] · · · · type [attribute] · xs:anySimpleType · {scope} A Scope Property Value {variety} local {parent} If the <attribute> <complexType> Complex Type Definition <attribute> <attributeGroup> Attribute Group Definition {value constraint} · · {inheritable} The · · inheritable [attribute] false {annotations} The · · <attribute> XML Representation of Annotation Schema Components (§3.15.2) If the <attribute> <complexType> <attributeGroup> ref [attribute] use='prohibited' XML Mapping Summary for Attribute Use Schema Component Property Representation {required} true use required false {attribute declaration} The (top-level) attribute declaration · · · · ref [attribute] {value constraint} If there is a default fixed [attribute] Value Constraint · · Property Value {variety} either default fixed {value} the · · [attribute] {attribute declaration} {type definition} {lexical form} the · · [attribute] {attribute declaration} {type definition} {inheritable} The · · inheritable [attribute] {attribute declaration} {inheritable} {annotations} The · · <attribute> XML Representation of Annotation Schema Components (§3.15.2) Schema Representation Constraint: Attribute Declaration Representation OK In addition to the conditions imposed on <attribute> all 1 default fixed must not 2 If default use use must · · optional 3 If the item's parent is not <schema> all must 3.1 One of ref name 3.2 If ref <simpleType> form type 4 The type <simpleType> must not 5 If fixed use use must not · · prohibited 6 targetNamespace all must 6.1 The name 6.2 The form 6.3 If the ancestor <schema> targetNamespace [attribute] · · · · targetNamespace <attribute> all 6.3.1 <attribute> <complexType> 6.3.2 There is a <restriction> <attribute> <complexType> · · base [attribute] <restriction> · · · xs:anyType · Informally, an attribute in an XML instance is locally · · · · xsi:type Local validity of attributes is tested as part of schema-validity · · [validity] · · A more formal statement is given in the following constraint. Validation Rule: Attribute Locally Valid For an attribute information item A · · D all must 1 D · · Missing Sub-components (§5.3) D A expanded name 2 D {type definition} · · 3 A · · · · D {type definition} String Valid (§3.16.4) 4 If D {value constraint} D {value constraint} {variety} fixed A · · D {value constraint} {value} 5 If D xsi:type Attribute Declaration for the 'type' attribute (§3.2.7.1) A · · · · [Definition:] · · · · governing attribute declaration 1 A declaration which was stipulated by the processor (see Assessing Schema-Validity (§5.2) 2 Its · · 3 A declaration · · [local name] [namespace name] · · · · · · · · · · Note: · · xsi:type xsi:nil xsi:schemaLocation xsi:noNamespaceSchemaLocation Built-in Attribute Declarations (§3.2.7) [Definition:] governing type definition · · 1 A type definition stipulated by the processor (see Assessing Schema-Validity (§5.2) 2 The {type definition} · · · · · · Schema-validity assessment of an attribute information item involves identifying its · · · · Validation Rule: Schema-Validity Assessment (Attribute) The schema-validity assessment of an attribute information item depends on its local · · For an attribute information item's schema-validity to have been assessed all must 1 A · · · · 2 Its local · · Attribute Locally Valid (§3.2.4.1) 3 Both clause 1 2 Attribute Locally Valid (§3.2.4.1) [Definition:] strictly assessed Schema Information Set Contribution: Assessment Outcome (Attribute) If the schema-validity of an attribute information item has been assessed as per Schema-Validity Assessment (Attribute) (§3.2.4.3) · · PSVI Contributions for [validation context] The nearest ancestor element information item with a [schema information] [validity] The appropriate case 1 If · · then case 1.1 If · · Attribute Locally Valid (§3.2.4.1) then valid 1.2 otherwise invalid 2 otherwise notKnown [validation attempted] The appropriate case 1 If · · then full 2 otherwise none [schema specified] infoset Attribute Default Value (§3.4.5.1) Schema Information Set Contribution: Validation Failure (Attribute) If and only if the local · · Attribute Locally Valid (§3.2.4.1) · · PSVI Contributions for [schema error code] The appropriate case 1 If · · then · · Outcome Tabulations (normative) (§B) 2 otherwise · · Schema Information Set Contribution: Attribute Declaration If and only if a · · · · PSVI Contributions for [attribute declaration] An · · · · [schema default] If the attribute information item is · · Attribute Use {lexical form} · · {lexical form} {value constraint} Schema Information Set Contribution: Attribute Validated by Type If and only if a · · · · PSVI Contributions for [schema normalized value] If the attribute's · · · · · · · · · · · · [schema actual value] If the [schema normalized value] · · · · · · [type definition] An · · · · [type definition type] simple [type definition namespace] The {target namespace} · · [type definition anonymous] true {name} · · · · false [type definition name] The {name} · · {name} · · · · {name} · · may · · · · Note: [type definition type] [type definition namespace] [type definition name] [type definition anonymous] [type definition] · · · · · · String Valid (§3.16.4) · · {variety} union PSVI Contributions for [member type definition] an · · · · [schema actual value] [member type definition namespace] The {target namespace} · · [member type definition anonymous] true {name} · · · · false [member type definition name] The {name} · · · · · · may · · · · The first ( · · · · If all 1 the attribute's · · · · · · 2 One 2.1 the · · {variety} list 2.2 the · · {variety} union · · [schema actual value] {variety} list 3 the {item type definition} {variety} union PSVI Contributions for [member type definitions] a sequence of Simple Type Definition [schema actual value] · · · · [schema actual value] See also Attribute Default Value (§3.4.5.1) Match Information (§3.4.5.2) Schema Information (§3.17.5.1) All attribute declarations (see Attribute Declarations (§3.2) must Schema Component Constraint: Attribute Declaration Properties Correct All must 1 The values of the properties of an attribute declaration are as described in the property tableau in The Attribute Declaration Schema Component (§3.2.1) Missing Sub-components (§5.3) 2 if there is a {value constraint} {type definition} Simple Default Valid (§3.2.6.2) Note: ID should Schema Component Constraint: Simple Default Valid For a Value Constraint V Simple Type Definition T all must 1 V {lexical form} · · T Datatype Valid [XML Schema: Datatypes] 2 V {lexical form} V {value} T xmlns Schema Component Constraint: xmlns The {name} must not xmlns Note: {name} · · xmlns:* xsi: Schema Component Constraint: xsi: The {target namespace} must not http://www.w3.org/2001/XMLSchema-instance Note: need must not Note: Attribute Use xsi: <xs:attribute ref="xsi:type" default="xs:integer"/> Element Locally Valid (Complex Type) (§3.4.4.2) Attribute Default Value (§3.4.5.1) There are four attribute declarations present in every schema by definition: xsi:type The xsi:type xsi:type (§2.7.1) Attribute Declaration for the 'type' attribute Property Value {name} type {target namespace} http://www.w3.org/2001/XMLSchema-instance {type definition} The built-in QName {scope} A Scope Property Value {variety} global {parent} · · {value constraint} · · {annotations} · · xsi:nil The xsi:nil xsi:nil (§2.7.2) Attribute Declaration for the 'nil' attribute Property Value {name} nil {target namespace} http://www.w3.org/2001/XMLSchema-instance {type definition} The built-in boolean {scope} A Scope Property Value {variety} global {parent} · · {value constraint} · · {annotations} · · xsi:schemaLocation The xsi:schemaLocation xsi:schemaLocation, xsi:noNamespaceSchemaLocation (§2.7.3) Attribute Declaration for the 'schemaLocation' attribute Property Value {name} schemaLocation {target namespace} http://www.w3.org/2001/XMLSchema-instance {type definition} An anonymous simple type definition, as follows: Property Value {name} · · {target namespace} http://www.w3.org/2001/XMLSchema-instance {base type definition} The built in · xs:anySimpleType · {facets} · · {variety} list {item type definition} The built-in anyURI {annotations} · · {scope} A Scope Property Value {variety} global {parent} · · {value constraint} · · {annotations} · · xsi:noNamespaceSchemaLocation The xsi:noNamespaceSchemaLocation xsi:schemaLocation, xsi:noNamespaceSchemaLocation (§2.7.3) Attribute Declaration for the 'noNamespaceSchemaLocation' attribute Property Value {name} noNamespaceSchemaLocation {target namespace} http://www.w3.org/2001/XMLSchema-instance {type definition} The built-in anyURI {scope} A Scope Property Value {variety} global {parent} · · {value constraint} · · {annotations} · · 3.3.1 The Element Declaration Schema Component XML Representation of Element Declaration Schema Components Common Mapping Rules for Element Declarations Mapping Rules for Top-Level Element Declarations Mapping Rules for Local Element Declarations References to Top-Level Element Declarations Examples of Element Declarations Constraints on XML Representations of Element Declarations Element Declaration Validation Rules Selected and Instance-specified Type Definitions Type Override and Valid Substitutability Element Locally Valid (Element) Element Locally Valid (Type) Validation Root Valid (ID/IDREF) Schema-Validity Assessment (Element) Element Declaration Information Set Contributions Assessment Outcome (Element) Validation Failure (Element) Element Declaration Element Validated by Type Element Default Value Inherited Attributes Constraints on Element Declaration Schema Components Element Declaration Properties Correct Element Default Valid (Immediate) Substitution Group OK (Transitive) Substitution Group Element declarations provide for: Local · · Specifying default or fixed values for element information items; Establishing uniquenesses and reference constraint relationships among the values of related elements and attributes; Controlling the substitutability of elements through the mechanism of · · Example <xs:element name="PurchaseOrder" type="PurchaseOrderType"/>
<xs:element name="gift"> <xs:complexType> <xs:sequence> <xs:element name="birthday" type="xs:date"/> <xs:element ref="PurchaseOrder"/> </xs:sequence> </xs:complexType> </xs:element> XML representations of several different types of element declaration The element declaration schema component has the following properties: Schema Component: Term {annotations} A sequence of Annotation {name} An xs:NCName value. Required. {target namespace} An xs:anyURI value. Optional. {type definition} A Type Definition {type table} A Type Table {scope} A Scope {value constraint} A Value Constraint {nillable} An xs:boolean value. Required. {identity-constraint definitions} A set of Identity-Constraint Definition {substitution group affiliations} A set of Element Declaration {substitution group exclusions} A subset of { extension restriction {disallowed substitutions} A subset of { substitution extension restriction {abstract} An xs:boolean value. Required. Property Record: Type Table {alternatives} A sequence of Type Alternative {default type definition} A Type Alternative Property Record: Scope {variety} One of { global local {parent} Either a Complex Type Definition Model Group Definition {variety} local must · · Property Record: Value Constraint {variety} One of { default fixed {value} An · · {lexical form} A character string. Required. The {name} must · · For an element declaration E E {scope} {variety} global E E {scope} {variety} local E Complex Type Definition Model Group Definition E {scope} {parent} A · · {target namespace} · · · · {target namespace} · · An element information item is normally required to satisfy the {type definition} {type definition} · · · · {type definition} {type table} Element Declaration xsi:type xsi:type (§2.7.1) · · {type definition} If {nillable} true · · {type definition} xsi:nil true xsi:nil (§2.7.2) · · Element Locally Valid (Element) (§3.3.4.3) [Definition:] E nilled D all 1 E xsi:nil true 2 D {nillable} true E · · D D E · · {value constraint} {value constraint} {variety} default · · [schema normalized value] · · {value constraint} {lexical form} fixed must fixed default must {value constraint} {value} Note: [schema normalized value] Note: {value constraint} {value constraint} {identity-constraint definitions} Identity-constraint Definitions (§3.11) The {substitution group affiliations} · · {substitution group affiliations} {substitution group affiliations} may {substitution group exclusions} {disallowed substitutions} An empty {substitution group exclusions} {substitution group affiliations} {type definition} · · {substitution group exclusions} extension restriction {type definition} extension restriction The supplied values for {disallowed substitutions} · · · · xsi:type (§2.7.1) extension restriction · · · · {disallowed substitutions} · · · · Element declarations for which {abstract} true must not · · See Annotations (§3.15) {annotations} The XML representation for an element declaration schema component is an <element> may · · XML Representation Summary element <element boolean #all extension restriction substitution string #all extension restriction string qualified unqualified ID nonNegativeInteger unbounded nonNegativeInteger NCName boolean QName QName anyURI QName {any attributes with non-schema namespace . . .} Content: annotation simpleType complexType alternative unique key keyref An <element> Top-level <element> <schema> global <element> <group> <complexType> global ref type <simpleType> <complexType> Note: <override> · · Overriding component definitions ( <override> Element information items · · must {target namespace} {target namespace} · · must · · must form [attribute] elementFormDefault [attribute] <schema> {target namespace} The names for top-level element declarations are in a separate · · Element Declarations Consistent (§3.8.6.3) Note that the above allows for two levels of defaulting for unspecified type definitions. An <element> substitutionGroup [attribute] · xs:anyType · name See XML Representation of Identity-constraint Definition Schema Components (§3.11.2) <key> <unique> <keyref> The following sections specify several sets of XML mapping rules which apply in different circumstances. If the <element> <schema> Element Declaration Common Mapping Rules for Element Declarations (§3.3.2.1) Mapping Rules for Top-Level Element Declarations (§3.3.2.2) If the <element> <complexType> <group> ref [attribute] minOccurs=maxOccurs=0 Particle Mapping Rules for Local Element Declarations (§3.3.2.3) Element Declaration Common Mapping Rules for Element Declarations (§3.3.2.1) Mapping Rules for Local Element Declarations (§3.3.2.3) If the <element> <complexType> <group> ref [attribute] minOccurs=maxOccurs=0 Particle References to Top-Level Element Declarations (§3.3.2.4) If the <element> minOccurs=maxOccurs=0 Note: minOccurs maxOccurs <element> <element> <complexType> <group> The following mapping rules apply in all cases where an <element> Element Declaration XML Mapping Summary for Element Declaration Schema Component Property Representation {name} The · · name [attribute] {type definition} The first of the following that applies: 1 The type definition corresponding to the <simpleType> <complexType> [children] 2 The type definition · · · · type [attribute] 3 The declared {type definition} Element Declaration · · QName · · substitutionGroup [attribute] 4 · xs:anyType · {type table} A Type Table <alternative> [children] · · Property Value {alternatives} A sequence of Type Alternative <alternative> test [attribute] {default type definition} Depends upon the final <alternative> [children] test [attribute] <alternative> {default type definition} test {alternatives} {default type definition} Element Declaration {default type definition} case 1 If <alternative> test [attribute] then Type Alternative <alternative> 2 otherwise <alternative> test Type Alternative Property Value {test} · · {type definition} the {type definition} Element Declaration {annotations} the empty sequence. {nillable} The · · nillable [attribute] false {value constraint} If there is a default fixed [attribute] Value Constraint · · [Definition:] effective simple type definition {type definition} {type definition} {content type} {variety} simple {type definition} {content type} {simple type definition} string Property Value {variety} either default fixed {value} the · · · · [attribute] {lexical form} the · · · · [attribute] {identity- constraint definitions} A set consisting of the identity-constraint-definitions corresponding to all the <key> <unique> <keyref> [children] {substitution group affiliations} A set of the element declarations · · · · substitutionGroup [attribute] {disallowed substitutions} A set depending on the · · block [attribute] · · blockDefault [attribute] <schema> EBV case 1 If EBV then 2 If EBV #all then { extension restriction substitution } 3 otherwise · · Note: blockDefault [attribute] <schema> may extension restriction substitution {disallowed substitutions} are {substitution group exclusions} As for {disallowed substitutions} final finalDefault [attributes] block blockDefault [attributes] { extension restriction } {abstract} The · · abstract [attribute] false {annotations} The · · <element> <unique> <key> <keyref> [children] ref [attribute] XML Representation of Annotation Schema Components (§3.15.2) If the <element> <schema> Element Declaration Common Mapping Rules for Element Declarations (§3.3.2.1) XML Mapping Summary for Element Declaration Schema Component Property Representation {target namespace} The · · targetNamespace [attribute] <schema> · · {scope} A Scope Property Value {variety} global {parent} · · If the <element> <complexType> <group> ref [attribute] minOccurs=maxOccurs=0 Particle Element Declaration {term} Particle Particle XML Mapping Summary for Particle Schema Component Property Representation {min occurs} The · · minOccurs [attribute] 1 {max occurs} unbounded maxOccurs [attribute] unbounded · · maxOccurs [attribute] 1 {term} A (local) element declaration as given below. {annotations} The same annotations as the {annotations} {term} The <element> Common Mapping Rules for Element Declarations (§3.3.2.1) XML Mapping Summary for Element Declaration Schema Component Property Representation {target namespace} The appropriate case 1 If targetNamespace then · · 2 If targetNamespace one 2.1 form qualified 2.2 form <schema> elementFormDefault qualified then · · targetNamespace [attribute] <schema> · · 3 otherwise · · {scope} A Scope Property Value {variety} local {parent} If the <element> <complexType> Complex Type Definition <element> <group> Model Group Definition If the <element> <complexType> <group> ref [attribute] minOccurs=maxOccurs=0 Particle XML Mapping Summary for Particle Schema Component Property Representation {min occurs} The · · minOccurs [attribute] 1 {max occurs} unbounded maxOccurs [attribute] unbounded · · maxOccurs [attribute] 1 {term} The (top-level) element declaration · · · · ref [attribute] {annotations} The · · <element> XML Representation of Annotation Schema Components (§3.15.2) Example <xs:element name="unconstrained"/>
<xs:element name="emptyElt"> <xs:complexType> <xs:attribute ...>. . .</xs:attribute> </xs:complexType> </xs:element>
<xs:element name="contextOne"> <xs:complexType> <xs:sequence> <xs:element name="myLocalElement" type="myFirstType"/> <xs:element ref="globalElement"/> </xs:sequence> </xs:complexType> </xs:element>
<xs:element name="contextTwo"> <xs:complexType> <xs:sequence> <xs:element name="myLocalElement" type="mySecondType"/> <xs:element ref="globalElement"/> </xs:sequence> </xs:complexType> </xs:element> The first example above declares an element whose type, by default, is · xs:anyType · The last two examples illustrate the use of local element declarations. Instances of myLocalElement contextOne myFirstType contextTwo mySecondType Note: Example <xs:complexType name="facet"> <xs:complexContent> <xs:extension base="xs:annotated"> <xs:attribute name="value" use="required"/> </xs:extension> </xs:complexContent> </xs:complexType>
<xs:element name="facet" type="xs:facet" abstract="true"/>
<xs:element name="encoding" substitutionGroup="xs:facet"> <xs:complexType> <xs:complexContent> <xs:restriction base="xs:facet"> <xs:sequence> <xs:element ref="annotation" minOccurs="0"/> </xs:sequence> <xs:attribute name="value" type="xs:encodings"/> </xs:restriction> </xs:complexContent> </xs:complexType> </xs:element>
<xs:element name="period" substitutionGroup="xs:facet"> <xs:complexType> <xs:complexContent> <xs:restriction base="xs:facet"> <xs:sequence> <xs:element ref="annotation" minOccurs="0"/> </xs:sequence> <xs:attribute name="value" type="xs:duration"/> </xs:restriction> </xs:complexContent> </xs:complexType> </xs:element>
<xs:complexType name="datatype"> <xs:sequence> <xs:element ref="facet" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="name" type="xs:NCName" use="optional"/> . . . </xs:complexType> An example from a previous version of the schema for datatypes. The facet facet facet only · · facet · · facet either period encoding Example The following example illustrates conditional type assignment to an element, based on the value of one of the element's attributes. Each instance of the message messageType The type messageType kind kind <xs:complexType name="messageType" mixed="true"> <xs:sequence> <xs:any processContents="skip" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="kind"> <xs:simpleType> <xs:union> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="string"/> <xs:enumeration value="base64"/> <xs:enumeration value="binary"/> <xs:enumeration value="xml"/> <xs:enumeration value="XML"/> </xs:restriction> </xs:simpleType> <xs:simpleType> <xs:restriction base="xs:string"/> </xs:simpleType> </xs:union> </xs:simpleType> </xs:attribute> <xs:anyAttribute processContents="skip"/> </xs:complexType> Three restrictions of messageType messageTypeString kind="string" messageTypeBase64 kind="base64" kind="binary" messageTypeXML kind="xml" kind="XML" <xs:complexType name="messageTypeString"> <xs:simpleContent> <xs:restriction base="messageType"> <xs:simpleType> <xs:restriction base="xs:string"/> </xs:simpleType> </xs:restriction> </xs:simpleContent> </xs:complexType>
<xs:complexType name="messageTypeBase64"> <xs:simpleContent> <xs:restriction base="messageType"> <xs:simpleType> <xs:restriction base="xs:base64Binary"/> </xs:simpleType> </xs:restriction> </xs:simpleContent> </xs:complexType>
<xs:complexType name="messageTypeXML"> <xs:complexContent> <xs:restriction base="messageType"> <xs:sequence> <xs:any processContents="strict"/> </xs:sequence> </xs:restriction> </xs:complexContent> </xs:complexType> message messageType test <alternative> [children] kind <alternative> test <xs:element name="message" type="messageType"> <xs:alternative test="@kind='string'" type="messageTypeString"/> <xs:alternative test="@kind='base64'" type="messageTypeBase64"/> <xs:alternative test="@kind='binary'" type="messageTypeBase64"/> <xs:alternative test="@kind='xml'" type="messageTypeXML"/> <xs:alternative test="@kind='XML'" type="messageTypeXML"/> <xs:alternative type="messageType"/> </xs:element> Schema Representation Constraint: Element Declaration Representation OK In addition to the conditions imposed on <element> all must 1 default fixed 2 If the item's parent is not <schema> all 2.1 One of ref name 2.2 ref minOccurs maxOccurs id xs <annotation> 3 The <element> <simpleType> <complexType> type 4 targetNamespace all 4.1 name 4.2 form 4.3 If the ancestor <schema> targetNamespace [attribute] · · · · targetNamespace <element> all 4.3.1 <element> <complexType> 4.3.2 There is a <restriction> <element> <complexType> · · base [attribute] <restriction> · · · xs:anyType · 5 Every <alternative> test [attribute] <alternative> may [attribute] When an element is · · · · · · [attributes] [children] · · · · The · · {type definition} · · · · Element Declaration · · · · · · · · · · [Definition:] selected type definition S E E D · · E 1 If D {type table} S · · E D {type table} 2 If D {type table} S D {type definition} E · · E Note: Element Declaration Properties Correct (§3.3.6.1) D S · · D {type definition} S · xs:error · [Definition:] Type Table T E T conditionally selects S E {test} T {alternatives} Type Alternative · · E Type Alternative · · Type Alternative S conditionally selected E T case 1 If at least one Type Alternative T {alternatives} · · E S Type Alternative 2 If no Type Alternative T {alternatives} · · S T {default type definition} {type definition} [Definition:] instance-specified type definition 1 Among the element's attribute information items is one named xsi:type 2 The · · · · QName String Valid (§3.16.4) 3 The · · · · · · instance-specified type definition [Definition:] · · S override T 1 S · · E · · E 2 S · · T {disallowed substitutions} E · · · · T · · Note: T · · E T Assessing Schema-Validity (§5.2) E · · T T · · E Note: · · · · S T <override> [Definition:] S validly substitutable T K substitution extension restriction list union {disallowed substitutions} {prohibited substitutions} S T S T K T {prohibited substitutions} Type Derivation OK (Complex) (§3.4.6.5) S T S · · T K Type Derivation OK (Complex) (§3.4.6.5) S S · · T K Type Derivation OK (Simple) (§3.16.6.3) [Definition:] S · · T S validly substitutable T without limitation absolutely validly substitutable Sometimes one type S · · T S T T S · · [Definition:] S validly substitutable as a restriction T S · · T extension list union The concept of local validity of an element information item against an element declaration is an important part of the schema-validity · · · · [validity] [local element validity] · · Informally, an element is locally valid against an element declaration when: The declaration is present in the schema and the name of the element matches the name of the declaration. The element is declared concrete (i.e. not abstract). Any xsi:nil xsi:nil xsi:nil = 'true' xsi:nil='true' Any xsi:type · · {type definition} The element's content satisfies the appropriate constraints: If the element is empty and the declaration specifies a default value, the default is checked against the appropriate type definitions. Otherwise, the content of the element is checked against the · · The element satisfies all the identity constraints specified on the element declaration. Additionally, on the · · The following validation rule gives the normative formal definition of local validity of an element against an element declaration. Validation Rule: Element Locally Valid (Element) For an element information item E · · D all must 1 D · · E D expanded name 2 D {abstract} false 3 One 3.1 D {nillable} false E xsi:nil 3.2 D {nillable} true one 3.2.1 E xsi:nil 3.2.2 E xsi:nil false 3.2.3 E xsi:nil true E · · all 3.2.3.1 E [children] 3.2.3.2 D {value constraint} {variety} fixed 4 E · · T T · · · · E 5 case 5.1 If D {value constraint} E [children] E · · D then all 5.1.1 If E · · · · D {value constraint} · · Element Default Valid (Immediate) (§3.3.6.2) 5.1.2 The element information item with D {value constraint} {lexical form} · · · · · · Element Locally Valid (Type) (§3.3.4.4) 5.2 If D {value constraint} E [children] E · · D then all 5.2.1 E · · · · Element Locally Valid (Type) (§3.3.4.4) 5.2.2 If D {value constraint} {variety} fixed E · · D all 5.2.2.1 E [children] 5.2.2.2 The appropriate case 5.2.2.2.1 If E · · Complex Type Definition {content type} {variety} mixed then · · E D {value constraint} {lexical form} 5.2.2.2.2 If E · · Simple Type Definition Complex Type Definition {content type} {variety} simple then · · E D {value constraint} {value} 6 E · · {identity-constraint definitions} Identity-constraint Satisfied (§3.11.4) 7 If E · · · · Validation Root Valid (ID/IDREF) (§3.3.4.5) Note: xsi:type · · xsi:type · · · · · · E D E 4 xsi:type · · · · · · · · 5 · · [local type validity] · · · · The following validation rule specifies formally what it means for an element to be locally valid against a type definition. This concept is appealed to in the course of checking an element's local validity against its · · · · · · xs:anyType Informally, local validity against a type requires first that the type definition be present in the schema and not declared abstract. For a simple type definition, the element must lack attributes (except for namespace declarations and the special attributes in the xsi Validation Rule: Element Locally Valid (Type) For an element information item E · · T all must 1 T · · 2 If T T {abstract} false 3 The appropriate case 3.1 If T then all 3.1.1 E [attributes] xsi:type xsi:nil xsi:schemaLocation xsi:noNamespaceSchemaLocation 3.1.2 E [children] 3.1.3 If E · · · · · · T String Valid (§3.16.4) 3.2 If T then E · · T Element Locally Valid (Complex Type) (§3.4.4.2) The following validation rule specifies document-level ID/IDREF constraints checked on the · · · · Validation Rule: Validation Root Valid (ID/IDREF) For an element information item E · · · · all must 1 There is no ID/IDREF binding E [ID/IDREF table] [binding] 2 There is no ID/IDREF binding E [ID/IDREF table] [binding] See ID/IDREF Table (§3.17.5.2) ID/IDREF binding Note: Outcome Tabulations (normative) (§B) Note: xs:ID xs:ID In the following examples, DOC Y · xs:anyType · X xml:id xs:ID Z xs:ID In the document <DOC><X>abcd</X></DOC> abcd DOC X abcd DOC The superficially similar case <DOC><Y xml:id="abcd"/></DOC> DOC Y abcd Y For the document <DOC><Z xml:id="abcd">abcd</Z></DOC> Z abcd xml:id Z X But if DOC abcd xml:id abcd Z Z abcd DOC Note: · · 2 Note: [XML 1.1] ID/IDREF · · This section gives the top-level rule for · · Assessment begins with the identification of a · · · · · · The element's attributes are to be · · skip · · The element's children are to be · · skip · · · · · · · · · · xsi:type · · [Definition:] governing element declaration E · · 1 A declaration stipulated by the processor (see Assessing Schema-Validity (§5.2) 2 E · · 3 A declaration · · E [local name] [namespace name] E · · strict · · lax · · 4 · · E [local name] [namespace name] none 4.1 E · · 4.2 the processor has stipulated a type definition for E 4.3 a · · · · E E · · E · · · · [Definition:] governing type definition E · · 1 An · · · · Assessing Schema-Validity (§5.2) 2 A type definition stipulated by the processor (see Assessing Schema-Validity (§5.2) 3 An · · · · · · E 4 The · · E 5 The value · · E · · 6 An · · · · · · 7 The · · 8 An · · · · · · Validation Rule: Schema-Validity Assessment (Element) The schema-validity assessment of an element information item E 1 If E · · · · E must · · 2 If E · · E must not · · 3 Otherwise, E must · · [Definition:] E strictly assessed all 1 One 1.1 All 1.1.1 A · · E · · 1.1.2 E · · Element Locally Valid (Element) (§3.3.4.3) 1.1.3 If that evaluation involved the evaluation of Element Locally Valid (Type) (§3.3.4.4) 1 1.2 All 1.2.1 E · · 1.2.2 A · · E · · 1.2.3 The local · · E · · Element Locally Valid (Type) (§3.3.4.4) 2 E [attributes] case 2.1 If · · then Schema-Validity Assessment (Attribute) (§3.2.4.3) 2.2 otherwise 3 [children] case 3.1 If · · · · then Schema-Validity Assessment (Element) (§3.3.4.6) 3.2 If · · skip Wildcard then 3.3 otherwise · · · xs:anyType · [Definition:] E laxly assessed both 1 E · · · · 2 E · · · xs:anyType · Element Locally Valid (Type) (§3.3.4.4) E [attributes] [children] 2 3 Schema-Validity Assessment (Element) (§3.3.4.6) Note: · · · · · · Schema Information Set Contribution: Assessment Outcome (Element) If and only if the schema-validity of an element information item has been assessed as per Schema-Validity Assessment (Element) (§3.3.4.6) · · PSVI Contributions for [validation context] The nearest ancestor element information item with a [schema information] [validity] The appropriate case 1 If · · then case 1.1 If all 1.1.1 One 1.1.1.1 clause 1.1 Schema-Validity Assessment (Element) (§3.3.4.6) · · Element Locally Valid (Element) (§3.3.4.3) 1.1.1.2 clause 1.2 Schema-Validity Assessment (Element) (§3.3.4.6) · · Element Locally Valid (Type) (§3.3.4.4) 1.1.2 Neither its [children] [attributes] [validity] invalid 1.1.3 Neither its [children] [attributes] · · strict · · [validity] notKnown then valid 1.2 otherwise invalid 2 otherwise notKnown [validation attempted] The appropriate case 1 If · · [children] [attributes] [validation attempted] full then full 2 If · · [children] [attributes] [validation attempted] none then none 3 otherwise partial Schema Information Set Contribution: Validation Failure (Element) If and only if the local · · Element Locally Valid (Element) (§3.3.4.3) Element Locally Valid (Type) (§3.3.4.4) · · PSVI Contributions for [schema error code] The appropriate case 1 If · · then · · Outcome Tabulations (normative) (§B) 2 otherwise · · [subsequence-valid] The appropriate case 1 If · · [attributes] [children] and 1 Element Locally Valid (Complex Type) (§3.4.4.2) [match information] none then true 2 otherwise false [failed identity constraints] A list of Identity-Constraint Definition Identity-constraint Satisfied (§3.11.4) Note: Identity-Constraint Definition [failed assertions] A list of Assertion Assertion Satisfied (§3.13.4.1) Note: Assertion Schema Information Set Contribution: Element Declaration If and only if a · · · · PSVI Contributions for [element declaration] an · · · · [nil] true 3.2.3 Element Locally Valid (Element) (§3.3.4.3) false [expected element declaration] if the element information item is · · · · {term} Particle · · Note: [element declaration] · · [expected element declaration] [declared type] an · · {type definition} · · [local element validity] The appropriate case 1 If · · Element Locally Valid (Element) (§3.3.4.3) then valid 2 otherwise · · Element Locally Valid (Element) (§3.3.4.3) invalid Schema Information Set Contribution: Element Validated by Type If and only if a · · · · PSVI Contributions for [schema normalized value] The appropriate case 1 If · · · · {content type} {variety} simple then case 1.1 If 5.1 Element Locally Valid (Element) (§3.3.4.3) then {lexical form} {value constraint} 1.2 If 5.1 Element Locally Valid (Element) (§3.3.4.3) not · · · · String Valid (§3.16.4) then · · · · 1.3 otherwise · · 2 otherwise · · [schema actual value] If the [schema normalized value] · · · · · · [type definition] An · · · · [type definition type] simple complex [type definition] [type definition namespace] [type definition] {target namespace} [type definition anonymous] true [type definition] {name} · · false [type definition name] If [type definition] {name} · · [type definition] {name} may · · · · [type fallback] A keyword indicating whether the expected type definition was unavailable and the element had a fallback type as its · · declared · · {type table} xsi:type · · · · {type definition} selected · · {type table} xsi:type · · · · · · lax · · · xs:anyType · none [type alternative] If the element's · · {type table} · · Type Alternative · · · · {default type definition} [local type validity] The appropriate case 1 If · · Element Locally Valid (Type) (§3.3.4.4) then valid 2 otherwise · · Element Locally Valid (Type) (§3.3.4.4) invalid [descendant validity] The appropriate case 1 If [children] [attributes] I I [validity] invalid I · · · · I [validity] notKnown then valid 2 otherwise invalid Note: [type definition type] [type definition namespace] [type definition name] [type definition anonymous] [type definition] Note: 5.1 Element Locally Valid (Element) (§3.3.4.3) {value} QName NOTATION · · · · [schema normalized value] [schema actual value] [schema normalized value] · · · · {variety} union {content type} {variety} simple {simple type definition} {variety} union PSVI Contributions for [member type definition] An · · · · [schema actual value] [member type definition namespace] The {target namespace} · · [member type definition anonymous] true {name} · · · · false [member type definition name] The {name} · · · · · · may · · · · The [type definition] · · [type definition type] [type definition namespace] [type definition name] [type definition anonymous] If all 1 the [schema normalized value] · · 2 One 2.1 the simple type definition used to validate the · · · · {simple type definition} {variety} list 2.2 the simple type definition has {variety} union · · [schema actual value] {variety} list 3 the {item type definition} {variety} union PSVI Contributions for [member type definitions] a sequence of Simple Type Definition [schema actual value] · · · · [schema actual value] Also, if the declaration has a {value constraint} PSVI Contributions for [schema default] The {lexical form} {value constraint} Note that if an element is · · [type definition] [member type definition] · xs:anyType · Schema Information Set Contribution: Element Default Value If and only if the local · · Element Locally Valid (Element) (§3.3.4.3) · · PSVI Contributions for [schema specified] The appropriate case 1 If 5.1 Element Locally Valid (Element) (§3.3.4.3) then schema 2 otherwise infoset See also Match Information (§3.4.5.2) Identity-constraint Table (§3.11.5) Validated with Notation (§3.14.5) Schema Information (§3.17.5.1) Schema Information Set Contribution: Inherited Attributes [Definition:] A Attribute Default Value (§3.4.5.1) potentially inherited E all 1 A [attributes] E 2 A E [validation context] 3 One 3.1 A · · Attribute Use {inheritable} true 3.2 A not · · Attribute Use A · · {inheritable} true If and only if an element information item P · · · · · · · · P [children] E · · skip Wildcard PSVI Contributions for [inherited attributes] A list of attribute information items. An attribute information item A all 1 A · · E 2 Let O A [owner element] A expanded name · · E [owner element] O All element declarations (see Element Declarations (§3.3) must Schema Component Constraint: Element Declaration Properties Correct For any element declaration E all must 1 The values of E The Element Declaration Schema Component (§3.3.1) Missing Sub-components (§5.3) 2 If E · · {value constraint} E {value constraint} E {type definition} Element Default Valid (Immediate) (§3.3.6.2) 3 If E {substitution group affiliations} E {scope} {variety} global 4 For each member M E {substitution group affiliations} E {type definition} · · M {type definition} M {substitution group exclusions} 5 There are no circular substitution groups. That is, it is not possible to return to E {substitution group affiliations} 6 If E {type table} Type Alternative E {type table} {alternatives} {test} · · 7 If E {type table} {type definition} T E {type table} {alternatives} E {type table} {default type definition} {type definition} one 7.1 T · · E {type definition} E {disallowed substitutions} 7.2 T · xs:error · This and the following sections define relations appealed to elsewhere in this specification. Schema Component Constraint: Element Default Valid (Immediate) For a Value Constraint V T case must 1 If T {content type} {variety} simple then V T T T T {content type} {simple type definition} Simple Default Valid (§3.2.6.2) 2 If T {content type} {variety} simple then all 2.1 T {content type} {variety} mixed 2.2 The particle T {content type} {particle} · · Particle Emptiable (§3.9.6.3) Schema Component Constraint: Substitution Group OK (Transitive) For an element declaration (call it M H one must 1 M H 2 All 2.1 H {disallowed substitutions} substitution 2.2 There is a chain of {substitution group affiliations} M H M {substitution group affiliations} H M {substitution group affiliations} {substitution group affiliations} H 2.3 The set of all {derivation method} · · M {type definition} H {type definition} H {disallowed substitutions} H {type definition} {prohibited substitutions} H {type definition} {prohibited substitutions} {type definition} · · M {type definition} H {type definition} [Definition:] substitutable Substitution Group OK (Transitive) (§3.3.6.3) [Definition:] HEAD {element declarations} substitution group {element declarations} substitution group HEAD · · HEAD 3.4.1 The Complex Type Definition Schema Component XML Representation of Complex Type Definition Schema Components Common Mapping Rules for Complex Type Definitions Mapping Rules for Complex Types with Simple Content Mapping Rules for Complex Types with Complex Content Mapping Rule for Attribute Uses Property Mapping Rule for Attribute Wildcard Property Examples of Complex Type Definitions Constraints on XML Representations of Complex Type Definitions Complex Type Definition Validation Rules Locally Declared Type Element Locally Valid (Complex Type) Element Sequence Locally Valid (Complex Content) Attribution Complex Type Definition Information Set Contributions Attribute Default Value Match Information Constraints on Complex Type Definition Schema Components Complex Type Definition Properties Correct Derivation Valid (Extension) Derivation Valid (Restriction, Complex) Content Type Restricts (Complex Content) Type Derivation OK (Complex) Built-in Complex Type Definition Complex Type Definitions provide for: Constraining element information items by providing Attribute Declaration (§2.2.2.3) [attributes] Constraining element information item [children] [children] Constraining elements and attributes to exist, not to exist, or to have specified values, with Assertion (§2.2.4.3) Using the mechanisms of Type Definition Hierarchy (§2.2.1.1) · · Specifying · · Limiting the ability to · · Controlling the permission to substitute, in an instance, elements of a · · Example <xs:complexType name="PurchaseOrderType"> <xs:sequence> <xs:element name="shipTo" type="USAddress"/> <xs:element name="billTo" type="USAddress"/> <xs:element ref="comment" minOccurs="0"/> <xs:element name="items" type="Items"/> </xs:sequence> <xs:attribute name="orderDate" type="xs:date"/> </xs:complexType> The XML representation of a complex type definition. A complex type definition schema component has the following properties: Schema Component: Complex Type Definition Type Definition {annotations} A sequence of Annotation {name} An xs:NCName value. Optional. {target namespace} An xs:anyURI value. Optional. {base type definition} A type definition {final} A subset of { extension restriction {context} Required if {name} · · must · · Either an Element Declaration Complex Type Definition {derivation method} One of { extension restriction {abstract} An xs:boolean value. Required. {attribute uses} A set of Attribute Use {attribute wildcard} A Wildcard {content type} A Content Type {prohibited substitutions} A subset of { extension restriction {assertions} A sequence of Assertion Property Record: Content Type {variety} One of { empty simple element-only mixed {particle} A Particle {variety} element-only mixed must · · {open content} An Open Content {variety} element-only mixed must · · {simple type definition} A Simple Type Definition {variety} simple must · · Property Record: Open Content {mode} One of { interleave suffix {wildcard} A Wildcard Complex type definitions are identified by their {name} {target namespace} {name} must · · {name} {target namespace} xsi:type (§2.7.1) <element> References to schema components across namespaces ( <import> Note: {name} ipso facto [(local) name] · · Element Declarations (§3.3) As described in Type Definition Hierarchy (§2.2.1.1) · · {base type definition} Simple Type Definition (§2.2.1.2) Complex Type Definition (§2.2.1.3) {derivation method} · · extension restriction Type Definition Hierarchy (§2.2.1.1) A complex type with an empty specification for {final} {base type definition} · · extension restriction · · [Definition:] final · · not · · final The {context} {type definition} Complex types for which {abstract} true {type definition} · · · · must not xsi:type (§2.7.1) {base type definition} {type definition} · · · · xsi:type (§2.7.1) · · {attribute uses} Element Locally Valid (Complex Type) (§3.4.4.2) Attribute Locally Valid (§3.2.4.1) · · {attribute wildcard} · · {attribute uses} Element Locally Valid (Complex Type) (§3.4.4.2) The Wildcard Schema Component (§3.10.1) Wildcard allows Expanded Name (§3.10.4.2) · · {content type} · · [children] A {content type} {variety} empty · · [children] A {content type} {variety} simple · · [children] {simple type definition} A {content type} {variety} element-only · · [children] · · {particle} A {content type} {variety} mixed · · [children] [children] · · {particle} A {content type} · · {open content} · · [children] · · {open content} Note: {derivation method} {content type} {base type definition} 5 {simple type definition} {content type} 4.1 4.2.1 {content type} Derivation Valid (Extension) (§3.4.6.2) Derivation Valid (Restriction, Complex) (§3.4.6.3) {prohibited substitutions} T T · · T as the · · E T · · E {type definition} E · · E xsi:type xsi:type (§2.7.1) as the · · E T {type definition} E · · Type Alternatives (§3.12) as the · · · · · · · · · · · · {type definition} T as the {type definition} Element Declaration E1 E1 Complex Type Definition D D Complex Type Definition B B Element Declaration E2 expanded name E1 E2 T {type definition} {prohibited substitutions} restriction · · T T {prohibited substitutions} extension · · T T {assertions} Assertions (§3.13) See Annotations (§3.15) {annotations} The XML representation for a complex type definition schema component is a <complexType> The XML representation for complex type definitions with a {content type} {variety} simple {content type} · · XML Representation Summary complexType <complexType boolean #all extension restriction #all extension restriction ID boolean NCName boolean {any attributes with non-schema namespace . . .} Content: annotation simpleContent complexContent openContent group all choice sequence attribute attributeGroup anyAttribute assert Note: <complexType name="anyThing"/> Note: be Constraints on Complex Type Definition Schema Components (§3.4.6) The following sections describe different sets of mapping rules for complex types; some are common to all or many source declarations, others only in specific circumstances. If the <complexType> <simpleContent> Complex Type Definition Mapping Rules for Complex Types with Simple Content (§3.4.2.2) Common Mapping Rules for Complex Type Definitions (§3.4.2.1) Mapping Rule for Attribute Uses Property (§3.4.2.4) Mapping Rule for Attribute Wildcard Property (§3.4.2.5) If the <complexType> <complexContent> Complex Type Definition Mapping Rules for Complex Types with Explicit Complex Content (§3.4.2.3.1) 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) Mapping Rule for Attribute Wildcard Property (§3.4.2.5) If the <complexType> <simpleContent> <complexContent> Complex Type Definition Mapping Rules for Complex Types with Implicit Complex Content (§3.4.2.3.2) 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) Mapping Rule for Attribute Wildcard Property (§3.4.2.5) 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} Whichever alternative for the content of <complexType> [attributes] [children] <complexType> XML Mapping Summary for Complex Type Definition Schema Component Property Representation {name} The · · name [attribute] · · {target namespace} The · · targetNamespace [attribute] <schema> · · {abstract} The · · abstract [attribute] false {prohibited substitutions} A set corresponding to the · · block [attribute] · · blockDefault [attribute] <schema> EBV case 1 If EBV then 2 If EBV #all then { extension restriction } 3 otherwise · · Note: blockDefault [attribute] <schema> may restriction extension {prohibited substitutions} are {final} As for {prohibited substitutions} final finalDefault [attributes] block blockDefault [attributes] {context} name [attribute] · · <element> Element Declaration <element> {assertions} A sequence whose members are Assertion 1 The {assertions} {base type definition} 2 Assertion <assert> [children] <complexType> <restriction> <extension> {annotations} The · · <complexType> <openContent> [child] <attributeGroup> [children] <simpleContent> <complexContent> [children] <restriction> <extension> [children] <openContent> <attributeGroup> [children] XML Representation of Annotation Schema Components (§3.15.2) Note: {base type definition} {assertions} {assertions} {base type definition} <simpleContent> <complexContent> <restriction> <extension> When the <complexType> <simpleContent> <attribute> <attributeGroup> <anyAttribute> Common Mapping Rules for Complex Type Definitions (§3.4.2.1) Mapping Rule for Attribute Uses Property (§3.4.2.4) Mapping Rule for Attribute Wildcard Property (§3.4.2.5) <restriction> <extension> must <simpleContent> XML Representation Summary simpleContent <simpleContent ID {any attributes with non-schema namespace . . .} Content: annotation restriction extension <restriction base QName ID {any attributes with non-schema namespace . . .} Content: annotation simpleType minExclusive minInclusive maxExclusive maxInclusive totalDigits fractionDigits length minLength maxLength enumeration whiteSpace pattern assertion {any with namespace: ##other} attribute attributeGroup anyAttribute assert <extension base QName ID {any attributes with non-schema namespace . . .} Content: annotation attribute attributeGroup anyAttribute assert When the <complexType> <simpleContent> <complexType> XML Mapping Summary for Complex Type Definition with simple content Schema Component Property Representation {base type definition} The type definition · · · · base [attribute] <restriction> <extension> <simpleContent> {derivation method} If the <restriction> restriction <extension> extension {content type} A Content Type Property Value {variety} simple {particle} · · {open content} · · {simple type definition} the appropriate case 1 If {base type definition} {content type} {variety} simple <restriction> then B 1.1 the simple type definition corresponding to the <simpleType> [children] <restriction> 1.2 otherwise ( <restriction> <simpleType> [children] {simple type definition} {content type} {base type definition} Property Value {name} · · {target namespace} The · · targetNamespace [attribute] <schema> · · {final} The empty set {context} The Complex Type Definition {content type} {simple type definition} {base type definition} B {facets} a set of facet components corresponding to the appropriate element information items among the <restriction> [children] Simple Type Restriction (Facets) (§3.16.6.4) {fundamental facets} Based on {variety} {facets} {base type definition} {member type definitions} Fundamental Facet The ordered Schema Component The bounded Schema Component The cardinality Schema Component The numeric Schema Component {variety} B {variety} {primitive type definition} B {primitive type definition} {item type definition} B {item type definition} {member type definitions} B {member type definitions} {annotations} The empty sequence 2 If {base type definition} {content type} {variety} mixed {particle} Particle · · Particle Emptiable (§3.9.6.3) <restriction> then S B <simpleType> [children] <restriction> · xs:anySimpleType · S B <restriction> [children] Simple Type Restriction (Facets) (§3.16.6.4) Note: <simpleType> [children] <restriction> S B · xs:anySimpleType · 1.1 Derivation Valid (Restriction, Simple) (§3.16.6.2) 3 If {base type definition} {content type} {variety} simple <extension> then {simple type definition} {content type} 4 If {base type definition} <extension> then 5 otherwise · xs:anySimpleType · When the <complexType> <simpleContent> <attribute> <attributeGroup> <anyAttribute> XML Representation of Attribute Declaration Schema Components (§3.2.2) Mapping Rule for Attribute Uses Property (§3.4.2.4) XML Representation of Wildcard Schema Components (§3.10.2) Common Mapping Rules for Complex Type Definitions (§3.4.2.1) Mapping Rule for Attribute Uses Property (§3.4.2.4) Mapping Rule for Attribute Wildcard Property (§3.4.2.5) Mapping Rules for Local Attribute Declarations (§3.2.2.2) Mapping Rules for References to Top-level Attribute Declarations (§3.2.2.3) <restriction> <extension> must <complexContent> <simpleContent> XML Representation Summary complexContent <complexContent ID boolean {any attributes with non-schema namespace . . .} Content: annotation restriction extension <restriction base QName ID {any attributes with non-schema namespace . . .} Content: annotation openContent group all choice sequence attribute attributeGroup anyAttribute assert <extension base QName ID {any attributes with non-schema namespace . . .} Content: annotation openContent group all choice sequence attribute attributeGroup anyAttribute assert <openContent ID none interleave suffix {any attributes with non-schema namespace . . .} Content: annotation any Complex types with complex content can be the image of two different forms of <complexType> <complexContent> Mapping Rules for Complex Types with Explicit Complex Content (§3.4.2.3.1) <simpleContent> <complexContent> Mapping Rules for Complex Types with Implicit Complex Content (§3.4.2.3.2) {content type} Mapping Rules for Content Type Property of Complex Content (§3.4.2.3.3) When the <complexType> <complexContent> 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) Mapping Rule for Attribute Wildcard Property (§3.4.2.5) XML Mapping Summary for Complex Type Definition with complex content Schema Component Property Representation {base type definition} The type definition · · · · base [attribute] {derivation method} If the <restriction> restriction <extension> extension When the <complexType> <simpleContent> <complexContent> · xs:anyType · 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) Mapping Rule for Attribute Wildcard Property (§3.4.2.5) XML Mapping Summary for Complex Type Definition with complex content Schema Component Property Representation {base type definition} · xs:anyType · {derivation method} restriction For complex types with complex content, the {content type} {content type} Mapping Rules for Complex Types with Simple Content (§3.4.2.2) Note: <complexType> abc xyz xyz abc xyz When the mapping rule below refers to "the [children] <complexType> <complexContent> [children] <extension> <restriction> <complexContent> <complexContent> [children] <complexType> The mapping rule also refers to the value of the {derivation method} XML Mapping Summary for Complex Type Definition with complex content Schema Component Property Representation {content type} 1 [Definition:] effective mixed case 1.1 If mixed [attribute] <complexContent> then · · 1.2 If mixed [attribute] <complexType> then · · 1.3 otherwise false Note: 5 Complex Type Definition Representation OK (§3.4.3) 1.1 1.2 2 [Definition:] explicit content case 2.1 If one 2.1.1 There is no <group> <all> <choice> <sequence> [children] 2.1.2 There is an <all> <sequence> [children] [children] <annotation> 2.1.3 There is among the [children] <choice> minOccurs [attribute] · · 0 [children] <annotation> 2.1.4 The <group> <all> <choice> <sequence> [children] maxOccurs [attribute] · · then empty 2.2 otherwise <all> <choice> <group> <sequence> [children] 3 [Definition:] effective content case 3.1 If · · empty then case 3.1.1 If · · true then Property Value {min occurs} 1 {max occurs} 1 {term} a model group whose {compositor} sequence {particles} 3.1.2 otherwise empty 3.2 otherwise · · 4 [Definition:] explicit content type case 4.1 If {derivation method} restriction then case 4.1.1 If · · empty then Content Type Property Value {variety} empty {particle} · · {open content} · · {simple type definition} · · 4.1.2 otherwise Content Type Property Value {variety} mixed · · true element-only {particle} The · · {open content} · · {simple type definition} · · 4.2 If {derivation method} extension then case 4.2.1 If {base type definition} {content type} {variety} empty simple then Content Type 4.1.1 4.1.2 4.2.2 If {base type definition} {content type} {variety} element-only mixed · · empty then {base type definition} {content type} 4.2.3 otherwise Content Type Property Value {variety} mixed · · true element-only {particle} [Definition:] base particle {content type} {base type definition} case 4.2.3.1 If {term} · · {compositor} all · · then · · 4.2.3.2 If {term} · · {compositor} all {term} · · {compositor} all then Particle {min occurs} the {min occurs} · · {max occurs} 1 {term} a model group whose {compositor} all {particles} {particles} {term} · · {particles} {term} · · 4.2.3.3 otherwise {min occurs} 1 {max occurs} 1 {term} a model group whose {compositor} sequence {particles} · · · · {open content} the {open content} {content type} {base type definition} {simple type definition} · · 5 [Definition:] wildcard element case 5.1 If <openContent> [child] then <openContent> [child] 5.2 If <openContent> [child] <schema> <defaultOpenContent> [child] one 5.2.1 the · · {variety} empty 5.2.2 the · · {variety} empty <defaultOpenContent> appliesToEmpty true then <defaultOpenContent> [child] <schema> 5.3 otherwise · · 6 Then the value of the property is the appropriate case 6.1 If · · · · mode 'none' then · · 6.2 otherwise Property Value {variety} The {variety} · · empty element-only {particle} The {particle} · · {variety} · · empty Particle Property Value {min occurs} 1 {max occurs} 1 {term} a model group whose {compositor} sequence {particles} {open content} An Open Content Property Value {mode} The · · mode [attribute] · · interleave {wildcard} Let W <any> [child] · · {open content} · · · · W {process contents} {annotations} W {namespace constraint} {namespace constraint} W {open content} {wildcard} · · Attribute Wildcard Union (§3.10.6.3) {simple type definition} · · Note: 4.2 Any <complexType> <attribute> <attributeGroup> <attribute> XML Representation of Attribute Declaration Schema Components (§3.2.2) XML Representation Summary attributeGroup <attributeGroup ID ref QName {any attributes with non-schema namespace . . .} Content: annotation The <attribute> <attributeGroup> {attribute uses} Complex Type Definition Note: [children] [children] <extension> <restriction> <simpleContent> <complexContent> <complexType> [children] <complexType> The rule also refers to the value of the {derivation method} XML Mapping Summary for Complex Type Definition (Attribute Uses) Schema Component Property Representation {attribute uses} If the <schema> defaultAttributes <complexType> defaultAttributesApply false {attribute uses} <attributeGroup> [child] ref [attribute] · · defaultAttributes [attribute] <attributeGroup> [children] <attributeGroup> [child] 1 The set of attribute uses corresponding to the <attribute> [children] 2 The {attribute uses} · · · · ref [attribute] <attributeGroup> [children] 3 The attribute uses "inherited" from the {base type definition} T case 3.1 If T {derivation method} extension then T {attribute uses} 3.2 If T {derivation method} restriction then T {attribute uses} {attribute declaration} expanded name one 3.2.1 the expanded name {attribute declaration} 1 2 3.2.2 the expanded name {attribute declaration} <attribute> [child] <attribute> use prohibited Note: T 3.3 otherwise Note: only prohibited use <attribute> {base type definition} <attribute> Complex Type Definition Validation Rules (§3.4.4) Constraints on Complex Type Definition Schema Components (§3.4.6) use prohibited The {attribute wildcard} Complex Type Definition <anyAttribute> <complexType> <complexType> <attributeGroup> Mapping Rule for Attribute Uses Property (§3.4.2.4) Note: References to "the [children] [children] <extension> <restriction> <simpleContent> <complexContent> <complexType> [children] <complexType> The rule also refers to the value of the {derivation method} XML Mapping Summary for Complex Type Definition (Attribute Wildcard) Schema Component Property Representation {attribute wildcard} If the <schema> defaultAttributes <complexType> defaultAttributesApply false {attribute wildcard} <attributeGroup> [child] ref [attribute] · · defaultAttributes [attribute] <attributeGroup> [children] <attributeGroup> [child] 1 [Definition:] complete wildcard Wildcard Common Rules for Attribute Wildcards (§3.6.2.2) 2 The value is then determined by the appropriate case 2.1 If {derivation method} restriction then · · 2.2 If {derivation method} extension then 2.2.1 [Definition:] base wildcard case 2.2.1.1 If {base type definition} {attribute wildcard} then {attribute wildcard} 2.2.1.2 otherwise · · 2.2.2 The value is then determined by the first case 2.2.2.1 If · · · · then · · 2.2.2.2 If · · · · then · · 2.2.2.3 otherwise {process contents} {annotations} · · {namespace constraint} {namespace constraint} · · · · Attribute Wildcard Union (§3.10.6.3) Example: Three ways to define a type for length The following declaration defines a type for specifications of length by creating a complex type with simple content, with xs:nonNegativeInteger unit <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> Example <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> A type definition for personal names, and a definition · · · · · · Example <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> A simplified type definition · · · · Example <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> An illustration of the abbreviated form, with the mixed complexType Example <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> A complex type definition that allows three explicitly declared child elements, in the specified order (but not necessarily adjacent), and furthermore allows additional elements of any name from any namespace other than the target namespace to appear anywhere in the children. Example To restrict away a local element declaration that · · expanded name <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> The restriction type quietComputer lax · · speaker Without the specification of the notQName · · speaker speaker speakerType quietComputer computer For example, if there is no notQName speaker quietComputer computer <speaker xsi:type="xs:string"/> The specific rule violated in this case is clause 2 Content type restricts (Complex Content) (§3.4.6.4) Schema Representation Constraint: Complex Type Definition Representation OK In addition to the conditions imposed on <complexType> all 1 If the <simpleContent> <complexType> must not mixed true 2 <restriction> <simpleContent> xs:enumeration xs:pattern xs:assertion may [children] <restriction> 3 If <openContent> mode 'none' must <any> [children] <openContent> 4 If <openContent> mode 'none' must not <any> [children] <openContent> 5 If the <complexContent> mixed [attribute] <complexType> <complexContent> · · [attributes] must This section defines the concept of · · · · · · · · [Definition:] Complex Type Definition expanded names locally declared type Complex Type Definition The attribute case is simpler and will be taken first. [Definition:] Complex Type Definition CTD A · · A CTD case 1 If CTD · xs:anyType · then · · 2 If A expanded name D {attribute declaration} Attribute Use CTD {attribute uses} then {type definition} D 3 otherwise · · A CTD {base type definition} The definition for elements is slightly more complex. [Definition:] Complex Type Definition CTD E · · E CTD case 1 If CTD · xs:anyType · then · · 2 If E expanded name D · · CTD · · · · · · then {type definition} D 3 otherwise · · E CTD {base type definition} Note: Element Declarations Consistent (§3.8.6.3) D Note: · · E · · · · · · CTD · · E Validation Rule: Element Locally Valid (Complex Type) For an element information item E · · T all must 1 E · · all 1.1 If T {content type} {variety} empty then E [children] 1.2 If T {content type} {variety} simple then E [children] · · E · · T {content type} {simple type definition} String Valid (§3.16.4) 1.3 If T {content type} {variety} element-only then E [children] [character code] white space [XML 1.1] 1.4 If T {content type} {variety} element-only T {content type} {variety} mixed then E [children] · · T {content type} Element Sequence Locally Valid (Complex Content) (§3.4.4.3) 2 A E [attributes] xsi:type xsi:nil xsi:schemaLocation xsi:noNamespaceSchemaLocation Built-in Attribute Declarations (§3.2.7) case 2.1 If {attribute uses} U {attribute declaration} expanded name A then A · · U Attribute Locally Valid (Use) (§3.5.4) U {attribute declaration} · · A Schema-Validity Assessment (Attribute) (§3.2.4.3) Assessment Outcome (Attribute) (§3.2.5.1) A · · U 2.2 otherwise all 2.2.1 There is an {attribute wildcard} 2.2.2 A · · Item Valid (Wildcard) (§3.10.4.1) A · · {attribute wildcard} 3 For each attribute use U T {attribute uses} U {required} true U {attribute declaration} expanded name E [attributes] Note: U · · 2.1 xsi:type 2.1 · · 4 For each · · A E {lexical form} A · · · · A {attribute declaration} {type definition} String Valid (§3.16.4) Note: {attribute wildcard} not {attribute uses} · · always · · {attribute declaration} 2 5 For each element information item in E [children] E [attributes] · · · · · · · · · · · · · · 6 E · · T {assertions} Assertion Satisfied (§3.13.4.1) [Definition:] defaulted attribute E · · T Attribute Use U all 1 U T {attribute uses} 2 U {required} false 3 U · · · · 4 U {attribute declaration} Attribute Declaration Built-in Attribute Declarations (§3.2.7) 5 U {attribute declaration} E [attributes] 2.1 Element Locally Valid (Complex Type) (§3.4.4.2) Validation Rule: Element Sequence Locally Valid (Complex Content) For a sequence S · · Content Type CT case must 1 If CT {open content} · · then S · · CT {particle} Element Sequence Locally Valid (Particle) (§3.9.4.2) 2 If CT {open content} {mode} suffix then S S1 S2 all 2.1 S S1 S2 2.2 S1 · · CT {particle} Element Sequence Locally Valid (Particle) (§3.9.4.2) 2.3 If S2 E S2 S1 E not · · CT {particle} 2.4 Every element in S2 · · CT {open content} {wildcard} Item Valid (Wildcard) (§3.10.4.1) 3 otherwise CT {open content} {mode} interleave S S1 S2 all 3.1 S S1 S2 All-groups (§3.8.4.1.3) 3.2 S1 · · CT {particle} Element Sequence Locally Valid (Particle) (§3.9.4.2) 3.3 For every element E S2 S3 S1 S3 E S S3 E not · · CT {particle} 3.4 Every element in S2 · · CT {open content} {wildcard} Item Valid (Wildcard) (§3.10.4.1) [Definition:] locally valid Content Type Element Sequence Locally Valid (Complex Content) (§3.4.4.3) Content Type [Definition:] · · · · [children] [attributes] attributed to When an attribute information item has the same expanded name {attribute declaration} Attribute Use attributed to Item Valid (Wildcard) (§3.10.4.1) attributed to not attributed to When a sequence S [child] · · {content type} CT S1 S2 S S S1 S2 S1 · · CT Element Sequence Locally Valid (Complex Content) (§3.4.4.3) for every element E S2 S3 S1 S3 E S S3 E not · · CT S1 · · CT {particle} Element Sequence Locally Valid (Complex Content) (§3.4.4.3) attributed to · · S1 attributed to {open content} CT S2 not attributed to Note: · · · · Content Type <xs:sequence> <xs:element name="a"/> <xs:element name="b"/> <xs:element name="c"/> </xs:sequence> <a/><b/><d/> · · · · [Definition:] · · [children] [attributes] · · · · {term} · · Attribute Use {attribute declaration} Attribute Use context-determined declarations 2.1 Element Locally Valid (Complex Type) (§3.4.4.2) 2 Element Sequence Locally Valid (Particle) (§3.9.4.2) Schema Information Set Contribution: Attribute Default Value For each · · · · [attributes] In addition, if necessary · · {attribute declaration} {target namespace} [local name] The {attribute declaration} {name} [namespace name] The {attribute declaration} {target namespace} [prefix] If the {attribute declaration} · · {target namespace} N [in-scope namespaces] N N [in-scope namespaces] · · If more than one prefix is bound to N [in-scope namespaces] · · If the {attribute declaration} · · {target namespace} N N [in-scope namespaces] · · · · Note: · · [in-scope namespaces] [namespace attributes] If the {attribute declaration} {target namespace} · · · · [normalized value] The · · {lexical form} [owner element] The element information item being assessed. [schema normalized value] The · · {lexical form} [schema actual value] The · · {value} [schema default] The · · {lexical form} [validation context] The nearest ancestor element information item with a [schema information] [validity] valid [validation attempted] full [schema specified] schema The added items
also have [type definition] [member type definition] [member type definitions] Attribute Validated by Type (§3.2.5.4) [Definition:] namespace fixup · · E N 1 If the [in-scope namespaces] E N E 2 Otherwise, first select some prefix P [in-scope namespaces] E · · 3 Add an entry to the [in-scope namespaces] E P N 4 Add a namespace attribute to the [namespace attributes] E 5 Maintain the consistency of the information set by adjusting the namespace bindings on the descendants of E 5.1 Add the binding of P N [in-scope namespaces] E P 5.2 Add to the [namespace attributes] E P P · · P [XML Namespaces 1.1] [Namespaces in XML 1.0] The choice between the two methods of maintaining consistency in the information set is · · · · [prefix] · · P Note: QName NOTATION · · · · [normalized value] [schema normalized value] [schema actual value] Schema Information Set Contribution: Match Information To allow users of the · · · · · · · · · · · · Element Locally Valid (Complex Type) (§3.4.4.2) [attributes] · · PSVI Contributions for [attribute attribution] The appropriate case 1 If · · Attribute Use then · · Attribute Use 2 If · · {attribute wildcard} then · · 3 otherwise · · Attribute Use {attribute wildcard} · · [match information] A keyword indicating what kind of component the attribute information item is · · case 1 If · · Attribute Use then attribute 2 If · · strict {attribute wildcard} then strict 3 If · · lax {attribute wildcard} then lax 4 If · · skip {attribute wildcard} then skip 5 otherwise · · Attribute Use {attribute wildcard} none And each element information item in its [children] · · PSVI Contributions for [element attribution] The appropriate case 1 If · · · · · · then · · Particle 2 If · · Open Content then · · Open Content 3 otherwise · · Particle Open Content · · [match information] A keyword indicating what kind of Particle · · case 1 If · · · · then element 2 If · · strict · · then strict 3 If · · lax · · then lax 4 If · · skip · · then skip 5 If · · Open Content then open 6 otherwise · · Particle Open Content none All complex type definitions (see Complex Type Definitions (§3.4) must Schema Component Constraint: Complex Type Definition Properties Correct All must 1 The values of the properties of a complex type definition are as described in the property tableau in The Complex Type Definition Schema Component (§3.4.1) Missing Sub-components (§5.3) 2 If the {base type definition} {derivation method} extension 3 There are no circular definitions, except for that of · xs:anyType · · xs:anyType · {base type definition} 4 No two distinct members of the {attribute uses} {attribute declaration} expanded name 5 If {content type} {open content} · · {content type} {variety} element-only mixed Schema Component Constraint: Derivation Valid (Extension) For every complex type T {base type definition} B T {derivation method} extension case must 1 If B then all 1.1 B {final} extension 1.2 B {attribute uses} T {attribute uses} U B {attribute uses} T {attribute uses} U 1.3 If B {attribute wildcard} T B {attribute wildcard} {namespace constraint} T {attribute wildcard} {namespace constraint} Wildcard Subset (§3.10.6.2) 1.4 One 1.4.1 B T {content type} {variety} simple {content type} {simple type definition} 1.4.2 B T {content type} {variety} empty 1.4.3 All 1.4.3.1 T {content type} {variety} element-only mixed 1.4.3.2 One 1.4.3.2.1 B {content type} {variety} empty 1.4.3.2.2 All 1.4.3.2.2.1 Both B T {content type} {variety} mixed {content type} {variety} element-only 1.4.3.2.2.2 T {content type} {particle} · · B {content type} {particle} Particle Valid (Extension) (§3.9.6.2) 1.4.3.2.2.3 One or more 1.4.3.2.2.3.1 B {content type} {open content} BOT · · 1.4.3.2.2.3.2 T {content type} {open content} EOT {mode} interleave 1.4.3.2.2.3.3 Both BOT EOT {mode} suffix 1.4.3.2.2.4 If neither BOT EOT · · BOT {wildcard} {namespace constraint} EOT {wildcard} {namespace constraint} Wildcard Subset (§3.10.6.2) 1.5 It is in principle possible to · · T {base type definition} · xs:anyType · Note: Constructing the intermediate type definition to check this constraint is straightforward: simply re-order the · · 1.6 For any element or attribute information item, its · · T · · · · B · · · · 1.7 B {assertions} T {assertions} 2 If B then all 2.1 T {content type} {variety} simple T {content type} {simple type definition} B 2.2 B {final} extension [Definition:] T valid extension {base type definition} T {derivation method} extension T Derivation Valid (Extension) (§3.4.6.2) Schema Component Constraint: Derivation Valid (Restriction, Complex) For every complex type T {base type definition} B T {derivation method} restriction all must 1 B {final} restriction 2 One or more 2.1 B · xs:anyType · 2.2 All 2.2.1 T {content type} {variety} simple 2.2.2 One 2.2.2.1 Let S B B {content type} {simple type definition} S T T {content type} {simple type definition} S T S B Type Derivation OK (Simple) (§3.16.6.3) 2.2.2.2 B {content type} {variety} mixed B {content type} {particle} Particle · · Particle Emptiable (§3.9.6.3) 2.3 All 2.3.1 T {content type} {variety} empty 2.3.2 One 2.3.2.1 B {content type} {variety} empty 2.3.2.2 B {content type} {variety} element-only mixed B {content type} {particle} Particle · · Particle Emptiable (§3.9.6.3) 2.4 All 2.4.1 One 2.4.1.1 T {content type} {variety} element-only B {content type} {variety} element-only mixed 2.4.1.2 T B {content type} {variety} mixed 2.4.2 The {content type} T · · B Content type restricts (Complex Content) (§3.4.6.4) 3 For every element information item E [attributes] E 2 3 Element Locally Valid (Complex Type) (§3.4.4.2) T B A E [attributes] B · · A · · T 4 For any element or attribute information item, its · · T · · · · B extension list union · · T B 5 B {assertions} T {assertions} [Definition:] {derivation method} restriction valid restriction {base type definition} Derivation Valid (Restriction, Complex) (§3.4.6.3) Note: T B T B The constraint just given, like other constraints on schemas, must T However, under certain conditions conforming processors need not (although they may T {content type} {particle} {term} {compositor} all 2.4.2 may · · T T {base type definition} T · · It is · · 2.4.2 T T {base type definition} · · Schema Component Constraint: Content type restricts (Complex Content) [Definition:] Content Type R · · {particle} restricts Content Type B all 1 Every sequence of element information items which is · · R · · B 2 For all sequences of element information items ES · · R E ES B · · E · · R [Definition:] ES · · Content Type CT AS 2 3 Element Locally Valid (Complex Type) (§3.4.4.2) Complex Type Definition E ES AS default binding Element Declaration Attribute Use strict lax skip 1 When the item has a · · Element Declaration 2 When the item has a · · · · Attribute Use Attribute Use 3 When the item has a · · · · Attribute Use {attribute declaration} · · {value constraint} · · {inheritable} · · {inheritable} Attribute Use 4 When the item is · · strict · · Open Content strict Wildcard · · · · strict 5 When the item is · · lax · · Open Content lax Wildcard · · · · lax 6 When the item is · · skip · · Open Content skip Wildcard skip [Definition:] · · G subsumes · · S one 1 G skip 2 G lax S skip 3 Both G S strict 4 G S all 4.1 Either G {nillable} true S {nillable} false 4.2 Either G {value constraint} fixed S fixed {value constraint} 4.3 S {identity-constraint definitions} G {identity-constraint definitions} 4.4 S G 4.5 S {type definition} · · G {type definition} 4.6 S {type table} G {type table} · · · · · · 5 G S Attribute Use all 5.1 S {attribute declaration} {type definition} · · G {attribute declaration} {type definition} Type Derivation OK (Simple) (§3.16.6.3) 5.2 Let GVC G · · SVC S · · one or more 5.2.1 GVC · · {variety} default 5.2.2 SVC {variety} fixed SVC {value} GVC {value} 5.3 G {inheritable} S {inheritable} Note: empty fixed Note: · · expanded name XML Representation of Complex Type Definition Schema Components (§3.4.2) The following constraint defines a relation appealed to elsewhere in this specification. Schema Component Constraint: Type Derivation OK (Complex) For a complex type definition (call it D · · · · B extension restriction all must 1 If B D {derivation method} D 2 One or more 2.1 B D 2.2 B D {base type definition} 2.3 All 2.3.1 D {base type definition} · xs:anyType · 2.3.2 The appropriate case 2.3.2.1 If D {base type definition} then · · B 2.3.2.2 If D {base type definition} then · · B Type Derivation OK (Simple) (§3.16.6.3) Note: xsi:type · · · · · · · · Note: 2.1 When they are both top-level components with the same component type, namespace name, and local name; When they are necessarily the same type definition (for example, when the two type definitions in question are the type definitions associated with two attribute or element declarations, which are discovered to be the same declaration); When they are the same by construction (for example, when an element's type definition defaults to being the same type definition as that of its substitution-group head or when a complex type definition inherits an attribute declaration from its base type definition). In other cases it is possible that conforming implementations will disagree as to whether components are identical. Note: S · · T S T There is a complex type definition for · xs:anyType · Complex Type Definition of anyType Property Value {name} anyType {target namespace} http://www.w3.org/2001/XMLSchema {base type definition} itself {derivation method} restriction {content type} A Content Type Property Value {variety} mixed {particle} a Particle Outer Particle for Content Type of anyType (§3.4.7) {simple type definition} · · {attribute uses} The empty set {attribute wildcard} a wildcard with the following properties:: Property Value {namespace constraint} A Namespace Constraint Property Value {variety} any {namespaces} The empty set {disallowed names} The empty set {process contents} lax {final} The empty set {context} · · {prohibited substitutions} The empty set {assertions} The empty sequence {abstract} false The outer particle of · xs:anyType · Outer Particle for Content Type of anyType Property Value {min occurs} 1 {max occurs} 1 {term} a model group with the following properties: Property Value {compositor} sequence {particles} a list containing one particle with the properties shown below in Inner Particle for Content Type of anyType (§3.4.7) The inner particle of · xs:anyType · Inner Particle for Content Type of anyType Property Value {min occurs} 0 {max occurs} unbounded {term} a wildcard with the following properties: Property Value {namespace constraint} A Namespace Constraint Property Value {variety} any {namespaces} The empty set {disallowed names} The empty set {process contents} lax Note: rational array text http://www.w3.org/2001/03/XMLSchema/TypeLibrary.xsd 3.5.1 The Attribute Use Schema Component XML Representation of Attribute Use Schema Components Constraints on XML Representations of Attribute Uses Attribute Use Validation Rules Attribute Use Information Set Contributions Constraints on Attribute Use Schema Components An attribute use is a utility component which controls the occurrence and defaulting behavior of attribute declarations. It plays the same role for attribute declarations in complex types that particles play for element declarations. Example <xs:complexType> . . . <xs:attribute ref="xml:lang" use="required"/> <xs:attribute ref="xml:space" default="preserve"/> <xs:attribute name="version" type="xs:decimal" fixed="1.0"/> </xs:complexType> XML representations which all involve attribute uses, illustrating some of the possibilities for controlling occurrence. The attribute use schema component has the following properties: Schema Component: Attribute Use Annotated Component {annotations} A sequence of Annotation {required} An xs:boolean value. Required. {attribute declaration} An Attribute Declaration {value constraint} A Value Constraint {inheritable} An xs:boolean value. Required. Property Record: Value Constraint {variety} One of { default fixed {value} An · · {lexical form} A character string. Required. {required} {attribute declaration} {value constraint} must {attribute declaration} {attribute declaration} {value constraint} See Annotations (§3.15) {annotations} Attribute uses correspond to all uses of <attribute> use two {attribute declaration} XML Representation of Attribute Declaration Schema Components (§3.2.2) None as such. [Definition:] effective value constraint U U {value constraint} U {attribute declaration} {value constraint} effective value constraint · · Validation Rule: Attribute Locally Valid (Use) For an attribute information item to be · · · · must {value} {value constraint} {variety} fixed None as such. All attribute uses (see Attribute Uses (§3.5) must Schema Component Constraint: Attribute Use Correct All must 1 The values of the properties of an attribute use U The Attribute Use Schema Component (§3.5.1) Missing Sub-components (§5.3) 2 If U {value constraint} · · U {attribute declaration} {type definition} Simple Default Valid (§3.2.6.2) 3 If U {attribute declaration} {value constraint} {variety} fixed U {value constraint} U {value constraint} {variety} fixed U {value constraint} {value} U {attribute declaration} {value constraint} {value} 3.6.1 The Attribute Group Definition Schema Component XML Representation of Attribute Group Definition Schema Components XML Mapping Rule for Named Attribute Groups Common Rules for Attribute Wildcards Constraints on XML Representations of Attribute Group Definitions Attribute Group Definition Validation Rules Attribute Group Definition Information Set Contributions Constraints on Attribute Group Definition Schema Components A schema can name a group of attribute declarations so that they can be incorporated as a group into complex type definitions. Attribute group definitions do not participate in · · {attribute uses} {attribute wildcard} may parameter entity <complexType> <attributeGroup> Example <xs:attributeGroup name="myAttrGroup"> <xs:attribute . . ./> . . . </xs:attributeGroup>
<xs:complexType name="myelement"> . . . <xs:attributeGroup ref="myAttrGroup"/> </xs:complexType> XML representations for attribute group definitions. The effect is as if the attribute declarations in the group were present in the type definition. The example above illustrates the pattern mentioned in XML Representations of Components (§3.1.2) attributeGroup attributeGroup name ref ref name The attribute group definition schema component has the following properties: Schema Component: Attribute Group Definition Annotated Component {annotations} A sequence of Annotation {name} An xs:NCName value. Required. {target namespace} An xs:anyURI value. Optional. {attribute uses} A set of Attribute Use {attribute wildcard} A Wildcard Attribute groups are identified by their {name} {target namespace} must · · References to schema components across namespaces ( <import> {attribute uses} {attribute wildcard} Complex Type Definitions (§3.4) · · See Annotations (§3.15) {annotations} The XML representation for an attribute group definition schema component is an <attributeGroup> · · XML Representation Summary attributeGroup <attributeGroup ID NCName QName {any attributes with non-schema namespace . . .} Content: annotation attribute attributeGroup anyAttribute When an <attributeGroup> <schema> <redefine> <complexType> <attributeGroup> Note: <attributeGroup> <override> · · Overriding component definitions ( <override> XML Mapping Summary for Attribute Group Definition Schema Component Property Representation {name} The · · name [attribute] {target namespace} The · · targetNamespace [attribute] <schema> · · {attribute uses} The union of the set of attribute uses corresponding to the <attribute> [children] {attribute uses} · · · · ref [attribute] <attributeGroup> [children] Note: <attributeGroup> <attributeGroup> {attribute wildcard} The Wildcard Common Rules for Attribute Wildcards (§3.6.2.2) <attributeGroup> {annotations} The · · <attributeGroup> <attributeGroup> [children] XML Representation of Annotation Schema Components (§3.15.2) Note: XML Representation of Complex Type Definition Schema Components (§3.4.2) Annotation Complex Type Definition Attribute Group Definition The rules given above for {attribute uses} {attribute wildcard} <attributeGroup> A B A [children] <attributeGroup> ref B A Attribute Group Definition {attribute uses} <attribute> [children] A B <attributeGroup> B Circular reference is not B <attributeGroup> B A <attributeGroup> {attribute uses} {attribute wildcard} <attribute> <any> Note: [children] <redefine> <attributeGroup> {attribute uses} {attribute wildcard} The following mapping for attribute-wildcards forms part of the XML mapping rules for different kinds of source declaration (most prominently <attributeGroup> <anyAttribute> Wildcard · · · · [Definition:] local wildcard E case 1 If E <anyAttribute> then Wildcard <anyAttribute> XML Representation of Wildcard Schema Components (§3.10.2) 2 otherwise · · The mapping is defined as follows: 1 Let L · · 2 Let W · · {attribute wildcard} E 3 The value is then determined by the appropriate case 3.1 If W then · · L 3.2 otherwise case 3.2.1 If L · · then Property Value {process contents} L {process contents} {annotations} L {annotations} {namespace constraint} the wildcard intersection of L {namespace constraint} {namespace constraint} W Attribute Wildcard Intersection (§3.10.6.4) 3.2.2 otherwise <anyAttribute> Property Value {process contents} The {process contents} W {namespace constraint} The wildcard intersection of the {namespace constraint} W Attribute Wildcard Intersection (§3.10.6.4) {annotations} · · Schema Representation Constraint: Attribute Group Definition Representation OK None as such. None as such. None as such. All attribute group definitions (see Attribute Group Definitions (§3.6) must Schema Component Constraint: Attribute Group Definition Properties Correct All must 1 The values of the properties of an attribute group definition are as described in the property tableau in The Attribute Group Definition Schema Component (§3.6.1) Missing Sub-components (§5.3) 2 No two distinct members of the {attribute uses} {attribute declaration} expanded name 3.7.1 The Model Group Definition Schema Component XML Representation of Model Group Definition Schema Components Constraints on XML Representations of Model Group Definitions Model Group Definition Validation Rules Model Group Definition Information Set Contributions Constraints on Model Group Definition Schema Components A model group definition associates a name and optional annotations with a Model Group {term} Model group definitions are provided primarily for reference from the XML Representation of Complex Type Definition Schema Components (§3.4.2) <complexType> <group> parameter entity Example <xs:group name="myModelGroup"> <xs:sequence> <xs:element ref="someThing"/> . . . </xs:sequence> </xs:group>
<xs:complexType name="trivial"> <xs:group ref="myModelGroup"/> <xs:attribute .../> </xs:complexType>
<xs:complexType name="moreSo"> <xs:choice> <xs:element ref="anotherThing"/> <xs:group ref="myModelGroup"/> </xs:choice> <xs:attribute .../> </xs:complexType> A minimal model group is defined and used by reference, first as the whole content model, then as one alternative in a choice. The model group definition schema component has the following properties: Schema Component: Model Group Definition Annotated Component {annotations} A sequence of Annotation {name} An xs:NCName value. Required. {target namespace} An xs:anyURI value. Optional. {model group} A Model Group Model group definitions are identified by their {name} {target namespace} must · · References to schema components across namespaces ( <import> Model group definitions per se · · {term} may {model group} Model Group See Annotations (§3.15) {annotations} The XML representation for a model group definition schema component is a <group> · · XML Representation Summary group <group ID nonNegativeInteger unbounded nonNegativeInteger NCName QName {any attributes with non-schema namespace . . .} Content: annotation all choice sequence If the item has <schema> <redefine> name [attribute] Note: <override> name [attribute] · · Overriding component definitions ( <override> XML Mapping Summary for Model Group Definition Schema Component Property Representation {name} The · · name [attribute] {target namespace} The · · targetNamespace [attribute] <schema> · · {model group} A model group which is the {term} <all> <choice> <sequence> [children] must {annotations} The · · <group> XML Representation of Annotation Schema Components (§3.15.2) Otherwise, if the item has a ref [attribute] not minOccurs=maxOccurs=0 <group> XML Mapping Summary for Particle Schema Component Property Representation {min occurs} The · · minOccurs [attribute] 1 {max occurs} unbounded maxOccurs [attribute] unbounded · · maxOccurs [attribute] 1 {term} The {model group} · · · · ref [attribute] {annotations} The · · <group> XML Representation of Annotation Schema Components (§3.15.2) Otherwise, the <group> minOccurs=maxOccurs=0 Note: ref name minOccurs maxOccurs <group> {min occurs} {max occurs} refer None as such. None as such. None as such. All model group definitions (see Model Group Definitions (§3.7) must Schema Component Constraint: Model Group Definition Properties Correct The values of the properties of a model group definition must The Model Group Definition Schema Component (§3.7.1) Missing Sub-components (§5.3) 3.8.1 The Model Group Schema Component XML Representation of Model Group Schema Components Constraints on XML Representations of Model Groups Model Group Validation Rules Language Recognition by Groups Principles of Validation against Groups Element Sequence Valid Model Group Information Set Contributions Constraints on Model Group Schema Components Model Group Correct All Group Limited Element Declarations Consistent Unique Particle Attribution Effective Total Range (all and sequence) Effective Total Range (choice) When the [children] empty Simple Type Definitions (§3.16) [children] may {term} [Definition:] directly contains {particles} [Definition:] indirectly contains · · · · [Definition:] contains · · · · Example <xs:group name="otherPets"> <xs:all> <xs:element name="birds"/> <xs:element name="fish"/> </xs:all> </xs:group> <xs:all> <xs:element ref="cats"/> <xs:element ref="dogs"/> <xs:group ref="otherPets"/> </xs:all>
<xs:sequence> <xs:choice> <xs:element ref="left"/> <xs:element ref="right"/> </xs:choice> <xs:element ref="landmark"/> </xs:sequence> XML representations for the three kinds of model group, the third nested inside the second. The model group schema component has the following properties: Schema Component: Model Group Term {annotations} A sequence of Annotation {compositor} One of { all choice sequence {particles} A sequence of Particle specifies a sequential ( sequence choice all {particles} [children] · · must ( sequence {particles} ( choice {particles} ( all {particles} When two or more element declarations contained · · · · · · {particles} must See Annotations (§3.15) {annotations} The XML representation for a model group schema component is either an <all> <choice> <sequence> · · XML Representation Summary all <all ID 0 1 0 1 {any attributes with non-schema namespace . . .} Content: annotation element any group <choice ID nonNegativeInteger unbounded nonNegativeInteger {any attributes with non-schema namespace . . .} Content: annotation element group choice sequence any <sequence ID nonNegativeInteger unbounded nonNegativeInteger {any attributes with non-schema namespace . . .} Content: annotation element group choice sequence any Each of the above items corresponds to a particle containing a model group, with properties as follows (unless minOccurs=maxOccurs=0 XML Mapping Summary for Particle Schema Component Property Representation {min occurs} The · · minOccurs [attribute] 1 {max occurs} unbounded maxOccurs [attribute] unbounded · · maxOccurs [attribute] 1 {term} A model group as given below. {annotations} The same annotations as the {annotations} The particle just described has a Model Group {term} XML Mapping Summary for Model Group Schema Component Property Representation {compositor} One of all choice sequence {particles} A sequence of particles corresponding to all the <all> <choice> <sequence> <any> <group> <element> [children] {annotations} The · · <all> <choice> <sequence> XML Representation of Annotation Schema Components (§3.15.2) None as such. In order to define the validation rules for model groups clearly, it will be useful to define some basic terminology; this is done in the next two sections, before the validation rules themselves are formulated. Each model group M L M · · M Within L M V M V M L M L M Unique Particle Attribution (§3.8.6.4) · · V M · · M M V M L M L M V M Principles of Validation against Groups (§3.8.4.2) [Definition:] S M · · S path S M S M S M Language Recognition by Groups (§3.8.4.1) Principles of Validation against Particles (§3.9.4.1) [Definition:] M S L M S M complete path incomplete paths <xs:sequence> <xs:element name="a"/> <xs:element name="b"/> <xs:element name="c"/> </xs:sequence> the sequences ( <a/><b/><c/> <a/><b/> · · · · · · <a/><b/><c/><d/> <a/><x/> Note: <xs:sequence> <xs:element name="a"/> <xs:element name="b"/> <xs:choice/> </xs:sequence> choice <a/> <a/><b/> The definitions of L M · · M M · · · · Principles of Validation against Particles (§3.9.4.1) This section defines L M · · M V M M If M Model Group {compositor} M sequence {particles} M P 1 P 2 P n L M S S 1 S 2 Sn S i L P i i n S 1 S 2 Sn · · S M P 1 P 2 P n L M P 1 P 2 P n [Definition:] partition may When M S · · S M Q Q 1 Q 2 Q j j n S S 1 S 2 S j S 1 S 2 S j · · S S i L P i i j Q i · · S i P i i j Example By this definition, some sequences which do not satisfy the entire model group nevertheless have · · M <xs:sequence> <xs:element name="a"/> <xs:element name="b"/> <xs:element name="c"/> </xs:sequence> and an input sequence S <a/><b/> where n j S 1 <a/> S 2 <b/> S · · M S L M · · Particle a Particle b When M V M · · M S L M · · M V M M · · · · · · · · · · S · · {particles} M Note: · · M · · · · · · M <xs:sequence> <xs:any minOccurs="0"/> <xs:element name="a" minOccurs="0"/> </xs:sequence> <a/> · · M · · · · · · Particle · · Note: L M V M M <xs:sequence> <xs:any minOccurs="0"/> <xs:element name="a"/> </xs:sequence> <a/><a/> L M V M a · · · · · · a · · · · a · · This section defines L M · · M V M M When the {compositor} M choice {particles} M P 1 P 2 P n L M L P 1 L P 2 L P n · · S P Q Q 1 Q 2 Q n Q i · · S P i i n M P 1 P 2 P n L M P 1 P 2 P n · · S P 1 P 2 P n · · S P The set V M · · M S L M · · M M · · · · · · · · Note: M <xs:choice> <xs:any/> <xs:element name="a"/> </xs:choice> · · <a/> · · · · · · · · · · This section defines L M · · M V M M When the {compositor} M all {particles} M P 1 P 2 P n L M S S 1 S 2 Sn i n S i L P i S 1 S 2 Sn · · S · · S P · · Q Q 1 Q 2 Q n Q i · · S i P i i n Less formally, when M all P 1 P 2 P n L M P 1 P 2 P n L M S S 1 S 2 Sn · · S i n S i L P i [Definition:] grouping For example, given the model group M <xs:all> <xs:element name="a" minOccurs="0" maxOccurs="5"/> <xs:element name="b" minOccurs="1" maxOccurs="1"/> <xs:element name="c" minOccurs="0" maxOccurs="5"/> </xs:all> S <a/><b/><a/> n S 1 <a/><a/> S 2 <b/> · · S M Particle a Particle b Particle a The set V M · · M S L M · · M Particles M · · · · · · Particle · · · · · · Note: M <xs:all> <xs:any/> <xs:element name="a"/> </xs:all> M a The other element can be anything at all, including a second a a · · · · · · <a/><a/> M · · a · · · · · · If the intention is not to allow the second a <xs:all> <xs:any notQName="a"/> <xs:element name="a"/> </xs:all> <a/><a/> It is possible for a given sequence of element information items to have multiple · · M M <xs:choice> <xs:sequence> <xs:element ref="my:a" maxOccurs="unbounded"/> <xs:element ref="my:b"/> </xs:sequence> <xs:sequence> <xs:element ref="my:a"/> <xs:element ref="my:b" maxOccurs="unbounded"/> </xs:sequence> </xs:choice> which can match the sequence ( <a/><b/> deterministic [XML 1.1] [Brüggemann-Klein / Wood 1998] <xs:sequence> <xs:element name="a" minOccurs="0"/> <xs:element name="a"/> </xs:sequence> Note: Unique Particle Attribution (§3.8.6.4) As noted above, each model group M L M L M · · M By imposing conditions on · · M · · M M Unique Particle Attribution (§3.8.6.4) S · · M V M · · M [Definition:] Particles P 1 P 2 Particle P compete S · · P P 1 P 2 For example, in the content model <xs:sequence> <xs:element name="a"/> <xs:choice> <xs:element name="b"/> <xs:any/> </xs:choice> </xs:sequence> the sequence ( <a/><b/> Q 1 Particle {term} a Particle {term} b Q 2 Particle {term} a Particle {term} Q 1 Q 2 Particles Q 1 Q 2 · · By contrast, in the content model <xs:choice> <xs:sequence> <xs:element name="a"/> <xs:element name="b"/> </xs:sequence> <xs:sequence> <xs:element name="c"/> <xs:any/> </xs:sequence> </xs:choice> Particles b · · · · P · · b · · [Definition:] · · S Particle P competing paths [Definition:] S P · · S P validation-path · · · · S · · · · Note: · · M Unique Particle Attribution (§3.8.6.4) S S · · M [Definition:] S locally valid P S · · P V P Validation Rule: Element Sequence Valid For a sequence S · · M S must V M Note: {particles} choice M {particles} L M M sequence all {particles} L M None as such. All model groups (see Model Groups (§3.8) must Schema Component Constraint: Model Group Correct All must 1 The values of the properties of a model group are as described in the property tableau in The Model Group Schema Component (§3.8.1) Missing Sub-components (§5.3) 2 There are no circular groups. That is, within the {particles} {term} Schema Component Constraint: All Group Limited When a model group has {compositor} all all must 1 It appears only as the value of one or more of the following properties: 1.1 the {model group} 1.2 the {term} Particle {max occurs} = 1 {particle} {content type} 1.3 the {term} Particle P {min occurs} = {max occurs} = 1 P {particles} Model Group {compositor} all 2 For every particle P {particles} P {term} P {term} {compositor} all Schema Component Constraint: Element Declarations Consistent If the {particles} {particles} · · expanded name must all must 1 All their declared {type definition} · · {name} 2 All their declared {type definition} {name} 3 All their declared {type definition} {target namespace} 4 All their {type table} · · · · If all 1 The {particles} · · expanded name Q EDS 2 At least one 2.1 The {particles} strict lax · · · · Q 2.2 The Model Group {term} · · Complex Type Definition CTD CTD {content type} {open content} strict lax Wildcard · · Q 3 There exists a top-level element declaration G expanded name Q {type table} EDS {type table} G must · · · · [Definition:] implicitly contains · · [Definition:] Type Table T1 equivalent Type Table T2 all 1 T1 {alternatives} T2 {alternatives} · · 2 T1 {default type definition} T2 {default type definition} · · [Definition:] Type Alternative equivalent Type Alternative T1 equivalent Type Alternative T2 T1 {test} T2 {test} T1 {type definition} T2 {type definition} · · must T1 T2 all 1 T1 {test} {namespace bindings} T2 {test} {namespace bindings} Namespace Binding T1 {test} {namespace bindings} T2 {test} {namespace bindings} {prefix} {namespace} 2 T1 {test} {default namespace} T2 {test} {default namespace} · · 3 T1 {test} {base URI} T2 {test} {base URI} · · 4 T1 {test} {expression} T2 {test} {expression} 5 T1 {type definition} T2 {type definition} may Note: may [Definition:] element particle Particle {term} Element Declaration [Definition:] wildcard particle Particle {term} Wildcard {process contents} {term} Schema Component Constraint: Unique Particle Attribution A content model must not · · · · · · · · Note: · · · · · · not Element Declaration · · · · Note: [XML 1.1] Analysis of the Unique Particle Attribution Constraint (non-normative) (§J) Since this constraint is expressed at the component level, it applies to content models whose origins (e.g. via type · · Note: Unique Particle Attribution (§3.8.6.4) · · S · · P S P Wildcard Element Declaration · · · · may · · · · · · · · · · · · Note: {target namespace} not Unique Particle Attribution (§3.8.6.4) Element Declarations Consistent (§3.8.6.3) all sequence The following constraints define relations appealed to elsewhere in this specification. Schema Component Constraint: Effective Total Range ( all sequence The effective total range of a particle P {term} G {compositor} all sequence minimum The product of P {min occurs} {min occurs} G {particles} G {particles} 0 {particles} maximum unbounded {max occurs} G {particles} G {particles} unbounded P {max occurs} unbounded P {max occurs} {max occurs} G {particles} G {particles} 0 {particles} choice Schema Component Constraint: Effective Total Range ( choice The effective total range of a particle P {term} G {compositor} choice minimum The product of P {min occurs} {min occurs} G {particles} G {particles} 0 {particles} maximum unbounded {max occurs} G {particles} G {particles} unbounded P {max occurs} unbounded P {max occurs} {max occurs} G {particles} G {particles} 0 {particles} 3.9.1 The Particle Schema Component XML Representation of Particle Schema Components Constraints on XML Representations of Particles Particle Validation Rules Principles of Validation against Particles Element Sequence Locally Valid (Particle) Element Sequence Accepted (Particle) Particle Information Set Contributions Constraints on Particle Schema Components Particle Correct Particle Valid (Extension) Particle Emptiable As described in Model Groups (§3.8) When an element is validated against a complex type, its sequence of child elements is checked against the content model of the complex type and the children are · · Particles Particles · · · · · · · · Particle Element Declaration Element Declaration · · · · · · · · · · · · {process contents} QName resolution (Instance) (§3.17.6.3) Example <xs:element ref="egg" minOccurs="12" maxOccurs="12"/>
<xs:group ref="omelette" minOccurs="0"/>
<xs:any maxOccurs="unbounded"/> XML representations which all involve particles, illustrating some of the possibilities for controlling occurrence. The particle schema component has the following properties: Schema Component: Particle Component {min occurs} An xs:nonNegativeInteger value. Required. {max occurs} Either a positive integer or unbounded {term} A Term {annotations} A sequence of Annotation In general, multiple element information item [children] [children] mixed · · {term} {min occurs} [children] must {min occurs} {min occurs} 0 Again, when the {term} [children] must {max occurs} {max occurs} unbounded When the {term} {min occurs} {max occurs} {term} {particles} [Definition:] directly contains {term} [Definition:] indirectly contains {term} [Definition:] contains · · · · See Annotations (§3.15) {annotations} minOccurs maxOccurs Local <element> XML Representation of Element Declaration Schema Components (§3.3.2) Model groups <all> <sequence> <choice> XML Representation of Model Group Schema Components (§3.8.2) Group references <group> XML Representation of Model Group Definition Schema Components (§3.7.2) Wildcard <any> XML Representation of Wildcard Schema Components (§3.10.2) None as such. Every particle P · · L P {min occurs} {max occurs} P L P P {term} Validation of Basic Terms (§3.9.4.1.2) Language Recognition for Repetitions (§3.9.4.1.1) When P {min occurs} P {max occurs} n P {term} T L P S S 1 S 2 Sn S i L T i n L P · · n n {term} P When P {min occurs} j P {max occurs} k P {term} T L P S S 1 S 2 Sn · · n n j n k k unbounded S i L T i n When P {min occurs} L P If (1) Particle P {min occurs} j {max occurs} k {term} T S S S 1 S 2 Sn S 1 S 2 Sn · · S n k k unbounded S i L T i n If T · · S P · · Q Q Q 1 Q 2 Q n Q i · · S i T i n · · Language Recognition by Groups (§3.8.4.1) If T · · · · S P n P Note: S P · · P P {max occurs} P P {term} {term} In the preceding section ( Language Recognition for Repetitions (§3.9.4.1.1) L P · · Particle P · · P {term} L T · · L T T Language Recognition by Groups (§3.8.4.1) [Definition:] Element Declaration D L D · · D · · D [Definition:] E matches Element Declaration D one 1 E D expanded name 2 The expanded name E · · D 2 · · D [Definition:] expanded name E matches · · N NS N NS match E The local name of E N Either the namespace name of E NS E E NS · · Note: expanded names · · Type Definition Element Declaration Attribute Declaration {name} {target namespace} · · expanded name expanded name · · {name} {target namespace} [Definition:] Wildcard W L W · · W · · W [Definition:] E matches Wildcard W · · {term} W E · · W Item Valid (Wildcard) (§3.10.4.1) [Definition:] N 1 N 2 match · · For principles of validation when the {term} · · Language Recognition by Groups (§3.8.4.1) Principles of Validation against Groups (§3.8.4.2) Validation Rule: Element Sequence Locally Valid (Particle) For a sequence (possibly empty) of element information items to be locally · · Particle all must 1 The sequence must be accepted by the Particle Element Sequence Accepted (Particle) (§3.9.4.3) Validation Rule: Element Sequence Accepted (Particle) For a sequence (possibly empty) of element information items to be accepted by a Particle P case must 1 If P {term} then all 1.1 The length of the sequence is greater than or equal to P {min occurs} 1.2 If P {max occurs} {max occurs} 1.3 Each element information item in the sequence is · · Item Valid (Wildcard) (§3.10.4.1) · · P · · 2 If P {term} D then all 2.1 The length of the sequence is greater than or equal to P {min occurs} 2.2 If P {max occurs} {max occurs} 2.3 For each element information item E one or more 2.3.1 D expanded name E In this case D · · E Schema-Validity Assessment (Element) (§3.3.4.6) Assessment Outcome (Element) (§3.3.5.1) 2.3.2 D D {scope} {variety} global {disallowed substitutions} substitution E expanded name · · S [Definition:] substituting declaration · S · · · D Substitution Group OK (Transitive) (§3.3.6.3) In this case · S · · · E Schema-Validity Assessment (Element) (§3.3.4.6) Assessment Outcome (Element) (§3.3.5.1) In this case E · · P Note: E · L D · 3 If P {term} then all 3.1 There is a · · n n P {min occurs} 3.2 If P {max occurs} n P {max occurs} 3.3 Each sub-sequence in the · · · · Element Sequence Valid (§3.8.4.3) · · Particles {term} Language Recognition by Groups (§3.8.4.1) Note: Unique Particle Attribution (§3.8.6.4) Wildcard Element Declaration Element Declaration Element Declaration · · {max occurs} Note: 1 2.3.2 not None as such. All particles (see Particles (§3.9) must Schema Component Constraint: Particle Correct All must 1 The values of the properties of a particle are as described in the property tableau in The Particle Schema Component (§3.9.1) Missing Sub-components (§5.3) 2 If {max occurs} unbounded all 2.1 {min occurs} {max occurs} The following constraint defines a relation appealed to elsewhere in this specification. Schema Component Constraint: Particle Valid (Extension) [Definition:] E valid extension B one or more 1 They are the same particle. 2 E {min occurs} E {max occurs} E {term} sequence {particles} B 3 All 3.1 E {min occurs} B {min occurs} 3.2 Both E B all {term} 3.3 The {particles} B all {particles} E all The following constraint defines a relation appealed to elsewhere in this specification. Schema Component Constraint: Particle Emptiable [Definition:] emptiable one or more 1 Its {min occurs} 0 2 Its {term} Effective Total Range ( all sequence all sequence Effective Total Range ( choice choice 0 3.10.1 The Wildcard Schema Component XML Representation of Wildcard Schema Components Mapping from <any> to a Particle Mapping from <any> and <anyAttribute> to a Wildcard Component Constraints on XML Representations of Wildcards Wildcard Validation Rules Item Valid (Wildcard) Wildcard allows Expanded Name Wildcard allows Namespace Name Wildcard Information Set Contributions Constraints on Wildcard Schema Components Wildcard Properties Correct Wildcard Subset Attribute Wildcard Union Attribute Wildcard Intersection In order to exploit the full potential for extensibility offered by XML plus namespaces, more provision is needed than DTDs allow for targeted flexibility in content models and attribute declarations. A wildcard provides for · · Example <xs:any processContents="skip"/>
<xs:any namespace="##other" processContents="lax"/>
<xs:any namespace="http://www.w3.org/1999/XSL/Transform" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" notQName="xsl:comment xsl:fallback"/> XML representations of the four basic types of wildcard, plus one attribute wildcard. The wildcard schema component has the following properties: Schema Component: Wildcard Term {annotations} A sequence of Annotation {namespace constraint} A Namespace Constraint {process contents} One of { skip strict lax Property Record: Namespace Constraint {variety} One of { any enumeration not {namespaces} A set each of whose members is either an xs:anyURI value or the distinguished value · · {disallowed names} A set each of whose members is either an xs:QName value or the keyword defined sibling {namespace constraint} · · ( {variety} any ( {variety} not {namespaces} · · · · example ##local · · {namespace constraint} ( {variety} enumeration {namespaces} · · · · ( {disallowed names} QName expanded name ( {disallowed names} defined expanded name ( {disallowed names} sibling expanded name {process contents} · · strict There must must xsi:type must · · skip No constraints at all: the item must lax If the item has a uniquely determined declaration available, it must · · · · See Annotations (§3.15) {annotations} The XML representation for a wildcard schema component is an <any> <anyAttribute> XML Representation Summary any <any ID nonNegativeInteger unbounded nonNegativeInteger ##any ##other anyURI ##targetNamespace ##local anyURI ##targetNamespace ##local QName ##defined ##definedSibling lax skip strict {any attributes with non-schema namespace . . .} Content: annotation XML Representation Summary anyAttribute <anyAttribute ID ##any ##other anyURI ##targetNamespace ##local anyURI ##targetNamespace ##local QName ##defined lax skip strict {any attributes with non-schema namespace . . .} Content: annotation An <any> minOccurs=maxOccurs=0 · · Processors may xs:anyURI namespace noNamespace ## Note: ## [XML Schema: Datatypes] The mapping from an <any> XML Mapping Summary for Particle Schema Component Property Representation {min occurs} The · · minOccurs [attribute] 1 {max occurs} unbounded maxOccurs unbounded · · maxOccurs [attribute] 1 {term} A wildcard as given below. {annotations} The same annotations as the {annotations} The mapping from an <any> <anyAttribute> <attributeGroup> <complexType> XML Mapping Summary for Wildcard Schema Component Property Representation {namespace constraint} A Namespace Constraint Property Value {variety} the appropriate case 1 If namespace [attribute] then case 1.1 If namespace "##any" then any 1.2 If namespace "##other" then not 1.3 otherwise enumeration 2 If notNamespace [attribute] then not 3 otherwise namespace notNamespace any {namespaces} the appropriate case 1 If namespace notNamespace then 2 If namespace "##any" then 3 If namespace "##other" then · · targetNamespace <schema> · · 4 otherwise · · namespace notNamespace [attribute] 4.1 if one such substring is ##targetNamespace · · targetNamespace [attribute] <schema> · · 4.2 if one such substring is ##local · · {disallowed names} If the notQName [attribute] · · notQName [attribute] If the item is a QName expanded name QName If the item is the token " ##defined defined If the item is the token " ##definedSibling sibling notQName [attribute] {process contents} The · · processContents [attribute] strict {annotations} The · · <any> XML Representation of Annotation Schema Components (§3.15.2) Note: XML Representation of Complex Type Definition Schema Components (§3.4.2) {annotations} · · <anyAttribute> Wildcards are subject to the same ambiguity constraints ( Unique Particle Attribution (§3.8.6.4) Schema Representation Constraint: Wildcard Representation OK In addition to the conditions imposed on <any> <anyAttribute> namespace notNamespace must not Validation Rule: Item Valid (Wildcard) I · · W all must 1 The expanded name I · · W {namespace constraint} Wildcard allows Expanded Name (§3.10.4.2) 2 If W {namespace constraint} {disallowed names} defined then both 2.1 If W W then expanded name I · · 2.2 If W then expanded name I · · 3 If all 3.1 W {namespace constraint} {disallowed names} sibling 3.2 W 3.3 I 3.4 I [parent] P 3.5 I P [validation context] 3.6 P · · T W · · then expanded name I · · · · T · · · · · · Informally, the keyword sibling W When an element or attribute information item is · · Item Valid (Wildcard) (§3.10.4.1) · · · · expanded name QName resolution (Instance) (§3.17.6.3) · · strict lax {process contents} skip · · [Definition:] skipped · · skip Validation Rule: Wildcard allows Expanded Name For an expanded name E · · C all must 1 The namespace name is · · C Wildcard allows Namespace Name (§3.10.4.3) 2 C {disallowed names} E Validation Rule: Wildcard allows Namespace Name For a value V · · · · C {namespace constraint} one must 1 C {variety} any 2 C {variety} not V C {namespaces} 3 C {variety} enumeration V C {namespaces} None as such. All wildcards (see Wildcards (§3.10) must Schema Component Constraint: Wildcard Properties Correct All must 1 The values of the properties of a wildcard are as described in the property tableau in The Wildcard Schema Component (§3.10.1) Missing Sub-components (§5.3) 2 If {variety} not {namespaces} 3 If {variety} any {namespaces} 4 The namespace name of each QName {disallowed names} {namespace constraint} Wildcard allows Namespace Name (§3.10.4.3) 5 Attribute wildcards do not contain sibling {namespace constraint} {disallowed names} The following constraints define a relation appealed to elsewhere in this specification. Schema Component Constraint: Wildcard Subset [Definition:] Namespace Constraint sub super sub wildcard subset super one 1 super {variety} any 2 Both sub super {variety} enumeration super {namespaces} sub {namespaces} 3 sub {variety} enumeration super {variety} not {namespaces} 4 Both sub super {variety} not super {namespaces} sub {namespaces} all 1 Each QName super {disallowed names} sub Wildcard allows Expanded Name (§3.10.4.2) 2 If super {disallowed names} defined sub {disallowed names} defined 3 If super {disallowed names} sibling sub {disallowed names} sibling Schema Component Constraint: Attribute Wildcard Union [Definition:] Namespace Constraint O O1 O2 O wildcard union O1 O2 {variety} {namespaces} {disallowed names} O O O1 O2 The {variety} {namespaces} O O O1 O2 one or more 1 O O1 O2 {variety} {namespaces} 2 Either O1 {variety} any O2 {variety} any O {variety} any 3 O O1 O2 {variety} enumeration O {namespaces} O1 {namespaces} O2 {namespaces} 4 O1 {variety} O2 {variety} not one 4.1 The intersection of the {namespaces} O1 O2 O {variety} any 4.2 O {variety} not O {namespaces} O1 {namespaces} O2 {namespaces} 5 Either O1 O2 {variety} not {namespaces} S1 {variety} enumeration {namespaces} S2 one 5.1 The set difference S1 S2 O {variety} any 5.2 O {variety} not O {namespaces} S1 S2 The {disallowed names} O O O1 O2 O {disallowed names} 1 QName O1 {disallowed names} O2 Wildcard allows Expanded Name (§3.10.4.2) 2 QName O2 {disallowed names} O1 3 The keyword defined O1 {disallowed names} O2 {disallowed names} Note: defined {disallowed names} defined not defined In the case where there are more than two Namespace Constraint Schema Component Constraint: Attribute Wildcard Intersection [Definition:] Namespace Constraint O O1 O2 O wildcard intersection O1 O2 {variety} {namespaces} {disallowed names} O O1 O2 The {variety} {namespaces} O O O1 O2 one or more 1 O O1 O2 {variety} {namespaces} 2 Either O1 O2 {variety} any O {variety} {namespaces} 3 O O1 O2 {variety} enumeration O {namespaces} {namespaces} O1 O2 4 O O1 O2 {variety} not O {namespaces} {namespaces} O1 O2 5 Either O1 O2 {variety} not {namespaces} S1 {variety} enumeration {namespaces} S2 O {variety} enumeration O {namespaces} S2 S1 The {disallowed names} O O O1 O2 O {disallowed names} 1 QName O1 {disallowed names} O2 Wildcard allows Namespace Name (§3.10.4.3) 2 QName O2 {disallowed names} O1 3 The keyword defined {disallowed names} In the case where there are more than two Namespace Constraint 3.11.1 The Identity-constraint Definition Schema Component XML Representation of Identity-constraint Definition Schema Components Constraints on XML Representations of Identity-constraint Definitions Identity-constraint Definition Validation Rules Identity-constraint Definition Information Set Contributions Constraints on Identity-constraint Definition Schema Components Identity-constraint Definition Properties Correct Selector Value OK Fields Value OK Identity-constraint definition components provide for uniqueness and reference constraints with respect to the contents of multiple elements and attributes. Example <xs:key name="fullName"> <xs:selector xpath=".//person"/> <xs:field xpath="forename"/> <xs:field xpath="surname"/> </xs:key>
<xs:keyref name="personRef" refer="fullName"> <xs:selector xpath=".//personPointer"/> <xs:field xpath="@first"/> <xs:field xpath="@last"/> </xs:keyref>
<xs:unique name="nearlyID"> <xs:selector xpath=".//*"/> <xs:field xpath="@id"/> </xs:unique> XML representations for the three kinds of identity-constraint definitions. The identity-constraint definition schema component has the following properties: Schema Component: Identity-Constraint Definition Annotated Component {annotations} A sequence of Annotation {name} An xs:NCName value. Required. {target namespace} An xs:anyURI value. Optional. {identity-constraint category} One of { key keyref unique {selector} An XPath Expression {fields} A sequence of XPath Expression {referenced key} An Identity-Constraint Definition {identity-constraint category} keyref {identity-constraint category} key unique must · · If a value is present, its {identity-constraint category} key unique Identity-constraint definitions are identified by their {name} {target namespace} must · · References to schema components across namespaces ( <import> Informally, {identity-constraint category} ( unique {selector} {fields} ( key unique key ( keyref {selector} {fields} {referenced key} These constraints are specified alongside the specification of types for the attributes and elements involved, i.e. something declared as of type integer can also serve as a key. Each constraint declaration has a name, which exists in a single symbol space for constraints. The equality and inequality conditions appealed to in checking these constraints apply to the values 3.0 3 either or Overall the augmentations to XML's ID/IDREF Functioning as a part of an identity-constraint is in addition to, not instead of, having a type; Not just attribute values, but also element content and combinations of values and content can be declared to be unique; Identity-constraints are specified to hold within the scope of particular elements; (Combinations of) attribute values and/or element content can be declared to be keys, that is, not only unique, but always present and non-nillable; The comparison between keyref {fields} key unique {fields} {selector} [XPath 2.0] must {fields} {selector} {fields} must must {fields} In order to reduce the burden on implementers, in particular implementers of streaming processors, only restricted subsets of XPath expressions are allowed in {selector} {fields} Constraints on Identity-constraint Definition Schema Components (§3.11.6) Note: xsl:key Note: [XSD 1.0 2E] [XPath 1.0] [XPath 2.0] See Annotations (§3.15) {annotations} The XML representation for an identity-constraint definition schema component is either a <key> <keyref> <unique> · · XML Representation Summary unique <unique ID NCName QName {any attributes with non-schema namespace . . .} Content: annotation selector field <key ID NCName QName {any attributes with non-schema namespace . . .} Content: annotation selector field <keyref ID NCName QName QName {any attributes with non-schema namespace . . .} Content: annotation selector field <selector ID xpath a subset of XPath expression, see below anyURI ##defaultNamespace ##targetNamespace ##local {any attributes with non-schema namespace . . .} Content: annotation <field ID xpath a subset of XPath expression, see below anyURI ##defaultNamespace ##targetNamespace ##local {any attributes with non-schema namespace . . .} Content: annotation If the ref [attribute] XML Mapping Summary for Identity-constraint Definition Schema Component Property Representation {name} The · · name [attribute] {target namespace} The · · targetNamespace [attribute] <schema> · · {identity- constraint category} One of key keyref unique {selector} An XPath Expression XML Representation of Assertion Schema Components (§3.13.2) <selector> xpath [attribute] {fields} A sequence of XPath Expression <field> [children] XML Representation of Assertion Schema Components (§3.13.2) <field> xpath [attribute] {referenced key} If the item is a <keyref> · · · · refer [attribute] · · {annotations} The · · <key> <keyref> <unique> <selector> <field> [children] XML Representation of Annotation Schema Components (§3.15.2) Otherwise (the ref [attribute] · · · · ref [attribute] Example <xs:element name="vehicle"> <xs:complexType> . . . <xs:attribute name="plateNumber" type="xs:integer"/> <xs:attribute name="state" type="twoLetterCode"/> </xs:complexType> </xs:element>
<xs:element name="state"> <xs:complexType> <xs:sequence> <xs:element name="code" type="twoLetterCode"/> <xs:element ref="vehicle" maxOccurs="unbounded"/> <xs:element ref="person" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType>
<!-- vehicles are keyed by their plate within states --> <xs:key name="reg"> <xs:selector xpath=".//vehicle"/> <xs:field xpath="@plateNumber"/> </xs:key> </xs:element>
<xs:element name="root"> <xs:complexType> <xs:sequence> . . . <xs:element ref="state" maxOccurs="unbounded"/> . . . </xs:sequence> </xs:complexType>
<!-- states are keyed by their code --> <xs:key name="state"> <xs:selector xpath=".//state"/> <xs:field xpath="code"/> </xs:key>
<xs:keyref name="vehicleState" refer="state"> <!-- every vehicle refers to its state --> <xs:selector xpath=".//vehicle"/> <xs:field xpath="@state"/> </xs:keyref>
<!-- vehicles are keyed by a pair of state and plate --> <xs:key name="regKey"> <xs:selector xpath=".//vehicle"/> <xs:field xpath="@state"/> <xs:field xpath="@plateNumber"/> </xs:key>
<!-- people's cars are a reference --> <xs:keyref name="carRef" refer="regKey"> <xs:selector xpath=".//car"/> <xs:field xpath="@regState"/> <xs:field xpath="@regPlate"/> </xs:keyref>
</xs:element>
<xs:element name="person"> <xs:complexType> <xs:sequence> . . . <xs:element name="car"> <xs:complexType> <xs:attribute name="regState" type="twoLetterCode"/> <xs:attribute name="regPlate" type="xs:integer"/> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> A state code vehicle person vehicle plateNumber state code plateNumber state plateNumber key vehicle person car regState regPlate vehicle carRef vehicle state state code Example <xs:element name="stateList"> <xs:complexType> <xs:sequence> . . . <xs:element name="state" maxOccurs="unbounded"> <xs:complexType> <xs:sequence> . . . <xs:element name="code" type="twoLetterCode"/> . . . </xs:sequence> </xs:complexType> </xs:element> . . . </xs:sequence> </xs:complexType>
<xs:key ref="state"/> <!-- reuse the key constraint from the above example --> </xs:element> A list of state stateList key code key state ref key Schema Representation Constraint: Identity-constraint Definition Representation OK In addition to the conditions imposed on <key> <keyref> <unique> all must 1 One of ref name 2 If name <selector> [children] 3 If name <keyref> refer 4 If ref id <annotation> ref 5 If ref {identity-constraint category} · · · · ref [attribute] Validation Rule: Identity-constraint Satisfied For an element information item E · · all must 1 A data model instance is constructed from the input information set, as described in [XDM] {selector} E XPath Evaluation (§3.13.4.2) [Definition:] target node set · · 2 Each node in the · · 3 N · · F {fields} N F XPath Evaluation (§3.13.4.2) S S · · · · {variety} simple F S · · [schema actual value] [schema actual value] V N F [Definition:] key-sequence N V N F {fields} Note: [schema actual value] · · default fixed may · · Note: · · N {fields} · · · · · · N N · · 4 [Definition:] qualified node set · · · · {fields} case 4.1 If {identity-constraint category} unique then · · · · Equality Identity [XML Schema: Datatypes] 4.2 If {identity-constraint category} key then all 4.2.1 The · · · · · · · · vice versa 4.2.2 No two members of the · · · · Equality Identity [XML Schema: Datatypes] 4.2.3 No element member of the · · · · · · {nillable} true 4.3 If {identity-constraint category} keyref then · · keyref member · · {referenced key} [identity-constraint table] E Identity-constraint Table (§3.11.5) · · keyref member's · · Equality Identity [XML Schema: Datatypes] Note: unique · · · · [schema actual value] Note: keyref 4.3 · · · · · · Note: · · 4.2.3 Element Declaration (§3.3.5.3) {nillable} must For purposes of checking identity-constraints, single atomic values are not distinguished from lists with single items. An atomic value V L V L Schema Information Set Contribution: Identity-constraint Table [Definition:] eligible identity-constraint 4.1 4.2 Identity-constraint Satisfied (§3.11.4) [children] [identity-constraint table] [Definition:] node table · · Whenever an element information item has one or more · · · · PSVI Contributions for [identity-constraint table] one Identity-constraint Binding · · PSVI Contributions for [definition] The · · [node table] A · · · · k n one 1 There is an entry in one of the · · [definition] Identity-constraint Binding [identity-constraint table] [children] · · k n 2 n · · k · · [definition] · · 1 1 · · Note: keyref · · The Identity-constraint Binding Identity-constraint Satisfied (§3.11.4) All identity-constraint definitions (see Identity-constraint Definitions (§3.11) must Schema Component Constraint: Identity-constraint Definition Properties Correct All must 1 The values of the properties of an identity-constraint definition are as described in the property tableau in The Identity-constraint Definition Schema Component (§3.11.1) Missing Sub-components (§5.3) 2 If the {identity-constraint category} keyref {fields} {fields} {referenced key} Schema Component Constraint: Selector Value OK All must 1 The {selector} XPath Valid (§3.13.6.2) 2 One or more 2.1 Its {expression} Selector XPath expressions Selector ::= Path Path Path ::= Step Step Step ::= '.' | NameTest NameTest ::= QName NCName 2.2 Its {expression} child For readability, whitespace may whitespace may token Lexical productions token ::= '.' | '/' | '//' | '|' | '@' | NameTest whitespace ::= S When tokenizing, the longest possible token is always returned. [Definition:] Selector Value OK (§3.11.6.2) selector subset Schema Component Constraint: Fields Value OK All must 1 Each member of the {fields} XPath Valid (§3.13.6.2) 2 For each member of the {fields} one or more 2.1 Its {expression} Selector Path in Field XPath expressions Path ::= ('.' '//')? ( Step Step NameTest 2.2 Its {expression} child attribute For readability, whitespace may whitespace may token When tokenizing, the longest possible token is always returned. [Definition:] Fields Value OK (§3.11.6.3) field subset 3.12.1 The Type Alternative Schema Component XML Representation of Type Alternative Schema Components Constraints on XML Representations of Type Alternatives Type Alternative Validation Rules Type Alternative Information Set Contributions Constraints on Type Alternative Schema Components Type Alternative components provide associations between boolean conditions (as XPath expressions) and Type Definition The type alternative schema component has the following properties: Schema Component: Type Alternative Annotated Component {annotations} A sequence of Annotation {test} An XPath Expression {type definition} A Type Definition Type alternatives can be used by an Element Declaration {test} {type definition} · · Element Declaration Element Declaration may Type Alternative {type table} The XML representation for a type alternative schema component is an <alternative> · · XML Representation Summary alternative <alternative ID an XPath expression QName anyURI ##defaultNamespace ##targetNamespace ##local {any attributes with non-schema namespace . . .} Content: annotation simpleType complexType Each <alternative> Type Alternative XML Mapping Summary for Type Alternative Schema Component Property Representation {test} If the test [attribute] · · XPath Expression XML Representation of Assertion Schema Components (§3.13.2) <alternative> test [attribute] {type definition} The type definition · · · · type [attribute] complexType simpleType [children] <alternative> {annotations} The · · <alternative> XML Representation of Annotation Schema Components (§3.15.2) Schema Representation Constraint: Type Alternative Representation OK <alternative> <alternative> must type complexType simpleType [Definition:] Type Alternative A successfully selects Type Definition T E A {test} true A {type definition} T {test} 1 [XDM] 1.1 · · 1.1.1 E 1.1.2 E [attributes] [children] 1.1.3 E [inherited attributes] expanded names E [attributes] E [attributes] E [owner element] [namespace name] · · P [namespace name] [prefix] P [Definition:] base information set properties Required Information Set Items and Properties (normative) (§D) 1.2 In the copy of E [parent] [children] 1.3 An [XDM] [XDM] 2 The XPath expression which is the value of the {test} XPath Evaluation (§3.13.4.2) dynamic error type error {test} false Note: Dynamic errors type errors {test} may Note: [XDM] E E {test} {type table} E [attributes] {test} None. All type alternatives (see Type Alternatives (§3.12) must Schema Component Constraint: Type Alternative Properties Correct All must 1 The values of the properties of a type alternatives are as described in the property tableau in The Type Alternative Schema Component (§3.12.1) Missing Sub-components (§5.3) 2 {test} · · XPath Valid (§3.13.6.2) function signatures static context must all 2.1 The fn:not [Functions and Operators] 2.2 Constructor functions for the built-in datatypes. function signatures · · A conforming processor must [XPath 2.0] Note: [XPath 2.0] may An XPath expression belongs to the required subset of XPath if and only if all 1 The {expression} XPath Expression [XPath 2.0] 2 One or more 2.1 It conforms to the following extended BNF: Test XPath expressions Test ::= OrExpr OrExpr ::= AndExpr AndExpr AndExpr ::= BooleanExpr BooleanExpr BooleanExpr ::= '(' OrExpr BooleanFunction ValueExpr Comparator ValueExpr BooleanFunction ::= QName OrExpr Comparator ::= '=' | '!=' | '<' | '<=' | '>' | '>=' ValueExpr ::= CastExpr ConstructorFunction CastExpr ::= SimpleValue SimpleValue ::= AttrName Literal AttrName ::= '@' NameTest ConstructorFunction ::= QName SimpleValue 2.2 It is an XPath expression involving the attribute Note: [XPath 2.0] [XPath 2.0] 3 Any strings matching the BooleanFunction fn:not [Functions and Operators] ConstructorFunction Note: function signatures static context 2 Type Alternative Properties Correct (§3.12.6) fn:not Note: a:b('123') BooleanFunction ConstructorFunction 4 Any explicit casts (i.e. any strings which match the optional " cast as QName CastExpr Note: may [XPath 2.0] Note: [XPath 2.0] 3.13.1 The Assertion Schema Component XML Representation of Assertion Schema Components Constraints on XML Representations of Assertions Assertion Validation Rules Assertion Satisfied XPath Evaluation Assertion Information Set Contributions Constraints on Assertion Schema Components Assertion Properties Correct XPath Valid Assertion components constrain the existence and values of related elements and attributes. Example <xs:assert test="@min le @max"/> The XML representation for assertions. The <assert> min max The assertion schema component has the following properties: Schema Component: Assertion Annotated Component {annotations} A sequence of Annotation {test} An XPath Expression Property Record: XPath Expression {namespace bindings} A set of Namespace Binding {default namespace} An xs:anyURI value. Optional. {base URI} An xs:anyURI value. Optional. {expression} An [XPath 2.0] Property Record: Namespace Binding {prefix} An xs:NCName value. Required. {namespace} An xs:anyURI value. Required. To check an assertion, an instance of the XPath 2.0 data model ( [XDM] · · Assertion Satisfied (§3.13.4.1) {test} true false true false fn:boolean See Annotations (§3.15) {annotations} The XML representation for an assertion schema component is an <assert> · · XML Representation Summary assert <assert ID test an XPath expression anyURI ##defaultNamespace ##targetNamespace ##local {any attributes with non-schema namespace . . .} Content: annotation The <assert> Assertion XML Mapping Summary for Assertion Schema Component Property Representation {test} An XPath Expression <assert> test [attribute] {annotations} The · · <assert> XML Representation of Annotation Schema Components (§3.15.2) Assertions, like identity constraints and conditional type assignment, use [XPath 2.0] XPath Expression designated attribute host element XML Mapping Summary for XPath Expression Property Record Property Representation {namespace bindings} A set of Namespace Binding [in-scope namespaces] {prefix} [prefix] {namespace} [namespace name] {default namespace} Let D · · xpathDefaultNamespace [attribute] xpathDefaultNamespace [attribute] <schema> case 1 If D ##defaultNamespace then case 1.1 If [in-scope namespaces] [prefix] · · then [namespace name] 1.2 otherwise · · 2 If D ##targetNamespace then case 2.1 If targetNamespace [attribute] <schema> then · · 2.2 otherwise · · 3 If D ##local then · · 4 otherwise D D {base URI} The [base URI] {expression} An XPath expression corresponding to the · · [attribute] Example <xs:complexType name="intRange"> <xs:attribute name="min" type="xs:int"/> <xs:attribute name="max" type="xs:int"/> <xs:assert test="@min le @max"/> </xs:complexType> The value of the min max int Example <xs:complexType name="arrayType"> <xs:sequence> <xs:element name="entry" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="length" type="xs:int"/> <xs:assert test="@length eq fn:count(./entry)"/> </xs:complexType> The value of the length entry None as such. Validation Rule: Assertion Satisfied An element information item E · · {test} true dynamic error type error Evaluation of {test} [XPath 2.0] 1 [XDM] 1.1 E · · Element Locally Valid (Element) (§3.3.4.3) · · · · Element Locally Valid (Complex Type) (§3.4.4.2) E 6 Element Locally Valid (Complex Type) (§3.4.4.2) Note: [attributes] [children] E 1.2 A "partial" · · E · · E [children] [attributes] E · · [validity] invalid notKnown [validation attempted] partial Note: · · E [validity] [validation attempted] By default, comments and processing instructions are excluded from the partial · · · · may Note: 1.3 From the "partial" · · [XDM] [XDM] E [attributes] [children] E Note: E E E 2 The XPath expression {test} XPath Evaluation (§3.13.4.2) 2.1 The root node of the [XDM] 1 context node 2.2 The static context $value Assertion Properties Correct (§3.13.6.1) 2.3 The variable " $value variable values dynamic context expanded QName value value case 2.3.1 If all 2.3.1.1 E [validity] · · invalid 2.3.1.2 E [nil] · · false 2.3.1.3 the {content type} E · · {variety} simple then value XDM representation E [schema actual value] {content type} {simple type definition} E · · Note: Note: . $value 1.2 anyType atomized untypedAtomic $value 2.3.2 otherwise · · E [validity] invalid E [nil] true E · · {content type} {variety} simple value 3 The evaluation result is converted to either true false fn:boolean Note: · · [XDM] must · · [XDM] Validation Rule: XPath Evaluation An XPath Expression X E [XPath 2.0] static context XPath Valid (§3.13.6.2) dynamic context 1 The context item E 2 The context position 3 The context size 4 The variable values 5 The function implementations function signatures static context XPath Valid (§3.13.6.2) 6 The current dateTime · · · · 7 The implicit timezone · · · · 8 The available documents 9 The available collections 10 The default collection It is · · [XPath 2.0] Note: None as such. All assertions (see Assertions (§3.13) must Schema Component Constraint: Assertion Properties Correct All must 1 The values of the properties of an assertion are as described in the property tableau in The Assertion Schema Component (§3.13.1) Missing Sub-components (§5.3) 2 {test} XPath Valid (§3.13.6.2) static context 2.1 The in-scope variables expanded QName value type anyAtomicType* 2.2 The function signatures all 2.2.1 Functions in the http://www.w3.org/2005/xpath-functions [Functions and Operators] 2.2.2 Constructor functions for the built-in datatypes. Note: anyAtomicType* $value Schema Component Constraint: XPath Valid For an XPath Expression X all must 1 The {expression} X [XPath 2.0] 2 X static error 2.1 The Static Typing Feature 2.2 The static context 2.2.1 XPath 1.0 compatibility mode false 2.2.2 The statically known namespaces {namespace bindings} X 2.2.3 The default element/type namespace {default namespace} X 2.2.4 The default function namespace http://www.w3.org/2005/xpath-functions 2.2.5 The in-scope schema definitions Built-in Attribute Declarations (§3.2.7) Built-in Complex Type Definition (§3.4.7) Built-in Simple Type Definitions (§3.16.7) 2.2.6 The in-scope variables 2.2.7 The context item static type Static Typing Feature 2.2.8 The function signatures · · Note: X Assertion Type Alternative Assertion Properties Correct (§3.13.6.1) Type Alternative Properties Correct (§3.12.6) 2.2.9 The statically known collations · · Unicode codepoint collation http://www.w3.org/2005/xpath-functions/collation/codepoint [Functions and Operators] 2.2.10 The default collation 2.2.11 The base URI {base URI} X 2.2.12 The statically known documents 2.2.13 The statically known collections · · 2.2.14 The statically known default collection type · · It is · · [XPath 2.0] Note: 3.14.1 The Notation Declaration Schema Component XML Representation of Notation Declaration Schema Components Constraints on XML Representations of Notation Declarations Notation Declaration Validation Rules Notation Declaration Information Set Contributions Constraints on Notation Declaration Schema Components Notation declarations reconstruct XML NOTATION declarations. Example <xs:notation name="jpeg" public="image/jpeg" system="viewer.exe"> The XML representation of a notation declaration. The notation declaration schema component has the following properties: Schema Component: Notation Declaration Annotated Component {annotations} A sequence of Annotation {name} An xs:NCName value. Required. {target namespace} An xs:anyURI value. Optional. {system identifier} An xs:anyURI value. Required if {public identifier} · · {public identifier} {public identifier} A publicID value. Required if {system identifier} · · {system identifier} As defined in [XML 1.0] [XML 1.1] Notation declarations do not participate in · · · · NOTATION · · · · NOTATION · · {name} See Annotations (§3.15) {annotations} The XML representation for a notation declaration schema component is a <notation> · · XML Representation Summary notation <notation ID name NCName token anyURI {any attributes with non-schema namespace . . .} Content: annotation The <notation> Notation Declaration XML Mapping Summary for Notation Declaration Schema Component Property Representation {name} The · · name [attribute] {target namespace} The · · targetNamespace [attribute] <schema> · · {system identifier} The · · system [attribute] · · {public identifier} The · · public [attribute] · · {annotations} The · · <notation> XML Representation of Annotation Schema Components (§3.15.2) Example <xs:notation name="jpeg" public="image/jpeg" system="viewer.exe" />
<xs:element name="picture"> <xs:complexType> <xs:simpleContent> <xs:extension base="xs:hexBinary"> <xs:attribute name="pictype"> <xs:simpleType> <xs:restriction base="xs:NOTATION"> <xs:enumeration value="jpeg"/> <xs:enumeration value="png"/> . . . </xs:restriction> </xs:simpleType> </xs:attribute> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element>
<picture pictype="jpeg">...</picture> None as such. None as such. Schema Information Set Contribution: Validated with Notation Whenever an attribute information item is · · NOTATION · · PSVI Contributions for [notation] An · · · · · · [notation system] The value of the {system identifier} [notation public] The value of the {public identifier} Note: should does Note: · · NOTATION · · All notation declarations (see Notation Declarations (§3.14) must Schema Component Constraint: Notation Declaration Correct The values of the properties of a notation declaration must The Notation Declaration Schema Component (§3.14.1) Missing Sub-components (§5.3) 3.15.1 The Annotation Schema Component XML Representation of Annotation Schema Components Constraints on XML Representations of Annotations Annotation Validation Rules Annotation Information Set Contributions Constraints on Annotation Schema Components Annotations provide for human- and machine-targeted annotations of schema components. Example <xs:simpleType fn:note="special"> <xs:annotation> <xs:documentation>A type for experts only</xs:documentation> <xs:appinfo> <fn:specialHandling>checkForPrimes</fn:specialHandling> </xs:appinfo> </xs:annotation> XML representations of three kinds of annotation. The annotation schema component has the following properties: Schema Component: Annotation Component {application information} A sequence of Element information items. {user information} A sequence of Element information items. {attributes} A set of Attribute information items. {user information} {application information} source · · not {user information} should xml:lang {attributes} Annotations do not participate in · · · · cannot · · The mapping defined in this specification from XML representations to components does not apply to XML elements contained within an <annotation> It is · · <annotation> The name [Definition:] Annotated Component Annotation of schemas and schema components, with material for human or computer consumption, is provided for by allowing application information and human information at the beginning of most major schema elements, and anywhere at the top level of schemas. The XML representation for an annotation schema component is an <annotation> · · XML Representation Summary annotation <annotation ID {any attributes with non-schema namespace . . .} Content: appinfo documentation <appinfo anyURI {any attributes with non-schema namespace . . .} Content: {any} <documentation anyURI language {any attributes with non-schema namespace . . .} Content: {any} The <annotation> Annotation XML Mapping Summary for Annotation Schema Component Property Representation {application information} A sequence of the <appinfo> [children] {user information} A sequence of the <documentation> [children] {attributes} A set of attribute information items, namely those allowed by the attribute wildcard in the type definition for the <annotation> The annotation component corresponding to the <annotation> {user information} {application information} {attributes} Virtually every kind of schema component defined in this specification has an {annotations} Annotation {annotations} [Definition:] annotation mapping ES AS 1 For every <annotation> [children] ES Annotation AS Note: {attributes} Annotation <annotation> [namespace name] 2 E ES A all 2.1 A E [attributes] 2.2 A [namespace name] 2.3 A [attributes] 1 E Annotation C AS C {application information} C {user information} C {attributes} A E [attributes] 3 AS Annotation [Definition:] annotation mapping · · Note: Annotation · · Note: Annotation {attributes} Annotation None as such. None as such. None as such: the addition of annotations to the · · · · All annotations (see Annotations (§3.15) must Schema Component Constraint: Annotation Correct The values of the properties of an annotation must The Annotation Schema Component (§3.15.1) Missing Sub-components (§5.3) 3.16.1 The Simple Type Definition Schema Component XML Representation of Simple Type Definition Schema Components Common mapping rules for Simple Type Definitions Mapping Rules for Atomic Simple Type Definitions Mapping Rules for Lists Mapping Rules for Unions Constraints on XML Representations of Simple Type Definitions Simple Type Definition Validation Rules Simple Type Definition Information Set Contributions Constraints on Simple Type Definition Schema Components Simple Type Definition Properties Correct Derivation Valid (Restriction, Simple) Type Derivation OK (Simple) Simple Type Restriction (Facets) Built-in Simple Type Definitions xs:anySimpleType xs:anyAtomicType xs:error Built-in primitive datatypes Other built-in datatypes Note: [XML Schema: Datatypes] Simple type definitions provide for constraining character information item [children] Example <xs:simpleType name="celsiusWaterTemp"> <xs:restriction base="xs:decimal"> <xs:fractionDigits value="2"/> <xs:minExclusive value="0.00"/> <xs:maxExclusive value="100.00"/> </xs:restriction> </xs:simpleType> The XML representation of a simple type definition. Schema Component: Simple Type Definition Type Definition {annotations} A sequence of Annotation {name} An xs:NCName value. Optional. {target namespace} An xs:anyURI value. Optional. {final} A subset of { extension restriction list union {context} Required if {name} · · must · · Either an Attribute Declaration Element Declaration Complex Type Definition Simple Type Definition {base type definition} A Type Definition With one exception, the {base type definition} Simple Type Definition Simple Type Definition · xs:anySimpleType · · xs:anyType · Complex Type Definition {base type definition} {facets} A set of Constraining Facet {fundamental facets} A set of Fundamental Facet {variety} One of { atomic list union Simple Type Definition · xs:anySimpleType · · · {primitive type definition} A Simple Type Definition {variety} atomic must · · · xs:anyAtomicType · {primitive type definition} · · If non- · · must primitive {item type definition} A Simple Type Definition {variety} list must · · The value of this property must {variety} atomic {variety} union must not {variety} list {member type definitions} A sequence of primitive or ordinary Simple Type Definition Must may {variety} union must · · The sequence may contain any primitive or ordinary simple type definition, but must not Simple types are identified by their {name} {target namespace} {name} must · · {name} {target namespace} xsi:type (§2.7.1) <element> <attribute> References to schema components across namespaces ( <import> Note: {name} ipso facto [(local) name] · · Element Declarations (§3.3) Attribute Declarations (§3.2) A simple type definition with an empty specification for {final} {base type definition} · · {item type definition} {member type definitions} extension restriction list union · · · · {variety} atomic list union [XML Schema: Datatypes] As described in Type Definition Hierarchy (§2.2.1.1) · · {base type definition} · xs:anySimpleType · · xs:anyAtomicType · · · · xs:anyAtomicType · {base type definition} atomic {primitive type definition} The {facets} atomic {primitive type definition} · · {primitive type definition} {facets} Constraining facets are defined in [XML Schema: Datatypes] must [XML Schema: Datatypes] · · must · · [XML Schema: Datatypes] As specified in [XML Schema: Datatypes] list · · {item type definition} must not list must [XML Schema: Datatypes] {facets} A union · · {member type definitions} list {facets} · xs:anySimpleType · · xs:anyAtomicType · must not {base type definition} See Annotations (§3.15) {annotations} As always, the mapping rules given in this section apply after, not before, the appropriate · · Note: [XML Schema: Datatypes] XML Representation Summary simpleType <simpleType #all list union restriction extension ID NCName {any attributes with non-schema namespace . . .} Content: annotation restriction list union <restriction QName ID {any attributes with non-schema namespace . . .} Content: annotation simpleType minExclusive minInclusive maxExclusive maxInclusive totalDigits fractionDigits length minLength maxLength enumeration whiteSpace pattern assertion explicitTimezone {any with namespace: ##other} <list ID QName {any attributes with non-schema namespace . . .} Content: annotation simpleType <union ID QName {any attributes with non-schema namespace . . .} Content: annotation simpleType The <simpleType> Simple Type Definition unknown <simpleType> Note: unknown · · unknown The following subsections define one set of common mapping rules for simple type definitions, and three specialized sets of mapping rules for atomic, list, and union datatypes, respectively. If the <simpleType> <restriction> {variety} atomic Common mapping rules for Simple Type Definitions (§3.16.2.1) Mapping Rules for Atomic Simple Type Definitions (§3.16.2.2) If the <simpleType> <list> <restriction> {variety} list Common mapping rules for Simple Type Definitions (§3.16.2.1) Mapping Rules for Lists (§3.16.2.3) If the <simpleType> <union> <restriction> {variety} union Common mapping rules for Simple Type Definitions (§3.16.2.1) Mapping Rules for Unions (§3.16.2.4) The following rules apply to all simple type definitions. XML Mapping Summary for Simple Type Definition Schema Component Property Representation {name} The · · name [attribute] <simpleType> · · {target namespace} The · · targetNamespace [attribute] <schema> · · {base type definition} The appropriate case 1 If <restriction> then · · · · base [attribute] <restriction> <simpleType> [children] <restriction> 2 If <list> <union> then · xs:anySimpleType · {final} A subset of { restriction extension list union } [Definition:] FS · · final [attribute] · · finalDefault [attribute] schema case 1 If · · then 2 If · · #all then { restriction extension list union } 3 otherwise · · restriction restriction extension list union {context} The appropriate case 1 If name [attribute] then · · 2 otherwise case 2.1 If <attribute> then Attribute Declaration 2.2 If <element> then Element Declaration 2.3 If <list> <union> then Simple Type Definition <simpleType> 2.4 If <alternative> then Element Declaration <element> 2.5 otherwise <restriction> case 2.5.1 If <simpleType> then Simple Type Definition 2.5.2 otherwise <simpleContent> Simple Type Definition {content type} {simple type definition} Complex Type Definition <complexType> {variety} If the <list> list <union> union <restriction> {variety} {base type definition} {facets} The appropriate case 1 If <restriction> and <restriction> <simpleType> <annotation> then Constraining Facet · · {facets} {base type definition} Constraining Facet [children] <restriction> Simple Type Restriction (Facets) (§3.16.6.4) 2 If <restriction> and <restriction> <simpleType> <annotation> then <simpleType> 3 If <list> then whiteSpace {value} collapse {fixed} true 4 otherwise {fundamental facets} Based on {variety} {facets} {base type definition} {member type definitions} Fundamental Facet The ordered Schema Component The bounded Schema Component The cardinality Schema Component The numeric Schema Component {annotations} The · · <simpleType> <restriction> <list> <union> [children] XML Representation of Annotation Schema Components (§3.15.2) The following rule applies if the {variety} atomic [Definition:] ancestors · · {base type definition} · · {base type definition} Simple Type Definition T · · <simpleType> T XML Mapping Summary for Atomic Simple Type Definition Schema Component Property Representation {primitive type definition} From among the · · Simple Type Definition Simple Type Definition primitive If the {variety} list XML Mapping Summary for List Simple Type Definition Schema Component Property Representation {item type definition} The appropriate case 1 If {base type definition} · xs:anySimpleType · then Simple Type Definition · · · · itemType [attribute] <list> <simpleType> [children] <list> Note: <list> itemType [attribute] <simpleType> [child] 2 otherwise {base type definition} · xs:anySimpleType · {item type definition} {base type definition} Note: <restriction> If the {variety} union XML Mapping Summary for Union Simple Type Definition Schema Component Property Representation {member type definitions} The appropriate case 1 If {base type definition} · xs:anySimpleType · then Simple Type Definition · · · · memberTypes [attribute] <union> <simpleType> [children] <union> Note: <union> memberTypes [attribute] <simpleType> [children] 2 otherwise {base type definition} · xs:anySimpleType · {member type definitions} {base type definition} Note: <restriction> Schema Representation Constraint: Simple Type Definition Representation OK In addition to the conditions imposed on <simpleType> all must 1 No two elements among the [children] <restriction> expanded name xs expanded name xs:enumeration xs:pattern xs:assertion Note: <enumeration> <pattern> <assertion> 2 If the <restriction> base [attribute] <simpleType> [children] 3 If the <list> itemType [attribute] <simpleType> [children] 4 If the <union> memberTypes [attribute] simpleType [child] Validation Rule: String Valid For a string S · · T all must 1 The · · S N whiteSpace facet pre-lexical facets T · · 2 N T Datatype Valid [XML Schema: Datatypes] 3 Let V · · N T Every · · V · · [Definition:] N T Datatype Valid · · V 1 The validating type V T T basic member T transitive membership · · N 2 If the · · V L {item type definition} L I validating type A V I I basic member I transitive membership · · N A [Definition:] · · · · · · T T ENTITY value · · · · ENTITY ID value · · ID [Definition:] declared entity name [name] [unparsedEntities] · · None as such. All simple type definitions must Schema Component Constraint: Simple Type Definition Properties Correct All must 1 The values of the properties of a simple type definition are as described in the property tableau in The Simple Type Definition Schema Component Missing Sub-components (§5.3) 2 All simple type definitions are, or are · · · xs:anySimpleType · · xs:anySimpleType · {base type definition} 3 The {final} {base type definition} restriction 4 There is not more than one member of {facets} 5 Each member of {facets} Note: must [XML Schema: Datatypes] · · unknown Schema Component Constraint: Derivation Valid (Restriction, Simple) Simple Type Definition D {base type definition} Simple Type Definition B case must 1 If D {variety} atomic then all 1.1 Either D · xs:anyAtomicType · B Note: · xs:anyAtomicType · {base type definition} · xs:anySimpleType · {variety} · · 1.2 B {final} restriction 1.3 For each facet in D {facets} DF all 1.3.1 DF D Applicable Facets [XML Schema: Datatypes] 1.3.2 DF Constraining Facets [XML Schema: Datatypes] 2 If D {variety} list then all 2.1 D {item type definition} D {item type definition} {variety} atomic D {item type definition} {variety} union {variety} list transitive membership 2.2 The appropriate case 2.2.1 If B · xs:anySimpleType · then all 2.2.1.1 D {item type definition} {final} list 2.2.1.2 D {facets} whiteSpace {value} collapse {fixed} true 2.2.2 otherwise all 2.2.2.1 B {variety} list 2.2.2.2 B {final} restriction 2.2.2.3 D {item type definition} · · B {item type definition} Type Derivation OK (Simple) (§3.16.6.3) 2.2.2.4 All facets in {facets} D Applicable Facets 2.2.2.5 All facets in {facets} Constraining Facets The first case above will apply when a list is constructed · · 3 If D {variety} union then all 3.1 D {member type definitions} 3.2 The appropriate case 3.2.1 If B · xs:anySimpleType · then all 3.2.1.1 All of the {member type definitions} {final} union 3.2.1.2 D {facets} 3.2.2 otherwise all 3.2.2.1 B {variety} union 3.2.2.2 B {final} restriction 3.2.2.3 Each type definition in D {member type definitions} · · B {member type definitions} Type Derivation OK (Simple) (§3.16.6.3) 3.2.2.4 All facets in {facets} D Applicable Facets 3.2.2.5 All facets in {facets} Constraining Facets The first case above will apply when a union is constructed · · 3.3 Neither D · · transitive membership [Definition:] T valid restriction {base type definition} T Derivation Valid (Restriction, Simple) (§3.16.6.2) The following constraint defines relations appealed to elsewhere in this specification. Schema Component Constraint: Type Derivation OK (Simple) For a simple type definition (call it D · · · · B extension restriction list union restriction S one must 1 They are the same type definition. 2 All 2.1 restriction S D {base type definition} {final} 2.2 One or more 2.2.1 D {base type definition} B 2.2.2 D {base type definition} · xs:anyType · · · B S 2.2.3 D {variety} list union B · xs:anySimpleType · 2.2.4 All 2.2.4.1 B {variety} union 2.2.4.2 D · · M B transitive membership S 2.2.4.3 The {facets} B intervening union Note: value space lexical space lexical mapping D B Note: 1 (§3.4.6.5) Note: S · · T S T Note: 2.2.4 (§3.16.6.2) Simple Type Definition transitive membership · · Schema Component Constraint: Simple Type Restriction (Facets) For a simple type definition (call it R B S all must 1 The {variety} R B 2 If {variety} atomic {primitive type definition} R B 3 The {facets} R {facets} B · · S Additional constraint(s) sometimes apply depending on the kind of facet, see the appropriate sub-section of 4.3 Constraining Facets [Definition:] B S overlaying B S R all 1 Every facet in S R 2 Every facet in B R S R 3 Every facet in R 1 2 xs:anySimpleType The Simple Type Definition anySimpleType Simple Type Definition of anySimpleType Property Value {name} ' anySimpleType {target namespace} ' http://www.w3.org/2001/XMLSchema {final} The empty set {context} · · {base type definition} · xs:anyType · {facets} The empty set {fundamental facets} The empty set {variety} · · {primitive type definition} · · {item type definition} · · {member type definitions} · · {annotations} The empty sequence The definition of · xs:anySimpleType · {base type definition} · xs:anyType · its {base type definition} xs:anyAtomicType The Simple Type Definition anyAtomicType Simple Type Definition of anyAtomicType Property Value {name} ' anyAtomicType {target namespace} ' http://www.w3.org/2001/XMLSchema {final} The empty set {context} · · {base type definition} · xs:anySimpleType · {facets} The empty set {fundamental facets} The empty set {variety} atomic {primitive type definition} · · {item type definition} · · {member type definitions} · · {annotations} The empty sequence xs:error A Simple Type Definition · xs:error · Simple Type Definition of xs:error Property Value {name} ' error {target namespace} ' http://www.w3.org/2001/XMLSchema {final} { extension restriction list union {context} · · {base type definition} · xs:anySimpleType · {facets} The empty set {fundamental facets} The empty set {variety} union {primitive type definition} · · {item type definition} · · {member type definitions} The empty sequence {annotations} The empty sequence Note: xs:error {member type definitions} xs:error The type xs:error · · Simple type definitions corresponding to all the built-in primitive datatypes, namely string boolean float double decimal dateTime duration time date gMonth gMonthDay gDay gYear gYearMonth hexBinary base64Binary anyURI QName NOTATION Primitive Datatypes [XML Schema: Datatypes] Simple Type Definition corresponding to the built-in primitive datatypes Property Value {name} [as appropriate] {target namespace} ' http://www.w3.org/2001/XMLSchema {base type definition} · xs:anyAtomicType · {final} The empty set {variety} atomic {primitive type definition} [this simple type definition itself] {facets} {a whitespace [value] collapse [fixed] true string [value] preserve [fixed] false {fundamental facets} [as appropriate] {context} · · {item type definition} · · {member type definitions} · · {annotations} The empty sequence All conforming implementations of this specification must [XML Schema: Datatypes] · · · · must · · [XML Schema: Datatypes] [Definition:] automatically known Note: · · Types · · Note: · · · · Similarly, simple type definitions corresponding to all the other built-in datatypes (see the Other Built-in Datatypes [XML Schema: Datatypes] [XML Schema: Datatypes] Illustrative XML representations for the built-in ordinary type definitions Simple Type Definition corresponding to the built-in ordinary datatypes Property Value {name} [as appropriate] {target namespace} ' http://www.w3.org/2001/XMLSchema {base type definition} [as specified in the appropriate sub-section of Other Built-in Datatypes {final} The empty set {variety} [ atomic list Other Built-in Datatypes {primitive type definition} [if {variety} atomic {primitive type definition} {base type definition} · · {facets} [as specified in the appropriate sub-section of Other Built-in Datatypes {fundamental facets} [as specified in the appropriate sub-section of Other Built-in Datatypes {context} · · {item type definition} if {variety} atomic · · Other Built-in Datatypes {member type definitions} · · {annotations} As shown in the XML representations of the ordinary built-in datatypes in Illustrative XML representations for the built-in ordinary type definitions All conforming implementations of this specification must [XML Schema: Datatypes] · · · · 3.17.1 The Schema Itself XML Representations of Schemas References to Schema Components References to Schema Components from Elsewhere Constraints on XML Representations of Schemas Validation Rules for Schemas as a Whole Schema Information Set Contributions Schema Information ID/IDREF Table Constraints on Schemas as a Whole Schema Properties Correct QName resolution (Schema Document) QName resolution (Instance) A schema consists of a set of schema components. Example <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.example.com/example"> . . . </xs:schema> The XML representation of the skeleton of a schema. At the abstract level, the schema itself is just a container for its components. Schema Component: Schema Annotated Component {annotations} A sequence of Annotation {type definitions} A set of Type Definition {attribute declarations} A set of Attribute Declaration {element declarations} A set of Element Declaration {attribute group definitions} A set of Attribute Group Definition {model group definitions} A set of Model Group Definition {notation declarations} A set of Notation Declaration {identity-constraint definitions} A set of Identity-Constraint Definition A schema is represented in XML by one or more · · <schema> · · {target namespace} · · <import> {target namespace} Import Constraints and Semantics (§4.2.6.2) As always, the mapping rules given in this section apply after, not before, the appropriate · · XML Representation Summary schema <schema qualified unqualified #all extension restriction substitution QName anyURI ##defaultNamespace ##targetNamespace ##local qualified unqualified #all extension restriction list union ID anyURI token language {any attributes with non-schema namespace . . .} Content: include import redefine override annotation defaultOpenContent annotation simpleType complexType group attributeGroup element attribute notation annotation <defaultOpenContent boolean ID interleave suffix {any attributes with non-schema namespace . . .} Content: annotation any The <schema> Schema XML Mapping Summary for Schema Schema Component Property Representation {type definitions} <simpleType> <complexType> [children] <include> Assembling a schema for a single target namespace from multiple schema definition documents ( <include> <override> Overriding component definitions ( <override> <redefine> Including modified component definitions ( <redefine> <import> References to schema components across namespaces ( <import> {attribute declarations} The (top-level) attribute declarations corresponding to all the <attribute> [children] <include> <override> <redefine> <import> {element declarations} The (top-level) element declarations corresponding to all the <element> [children] <include> <override> <redefine> <import> {attribute group definitions} The attribute group definitions corresponding to all the <attributeGroup> [children] <include> <override> <redefine> <import> {model group definitions} The model group definitions corresponding to all the <group> [children] <include> <redefine> <import> {notation declarations} The notation declarations corresponding to all the <notation> [children] <include> <override> <redefine> <import> {identity- constraint definitions} The identity-constraint definitions corresponding to all the <key> <keyref> <unique> [children] <include> <override> <redefine> <import> {annotations} The · · <schema> <include> <redefine> <override> <import> <defaultOpenContent> [children] XML Representation of Annotation Schema Components (§3.15.2) Note that none of the attribute information items displayed above correspond directly to properties of schemas. The blockDefault finalDefault attributeFormDefault elementFormDefault targetNamespace id version The definition of the schema abstract data model in XSD Abstract Data Model (§2.2) {target namespace} <schema> {target namespace} targetNamespace Since the empty string is not a legal namespace name, supplying an empty string for targetNamespace not · · {target namespace} targetNamespace Note: [XML Namespaces 1.1] {target namespace} Although the example schema at the beginning of this section might be a complete XML document, <schema> Aside from <include> <import> may <schema> <annotation> Reference to schema components from a schema document is managed in a uniform way, whether the component corresponds to an element information item from the same schema document or is imported ( References to schema components across namespaces ( <import> may · · [Definition:] QName [XML Namespaces 1.1] QName [XML Schema: Datatypes] · · · · QName expanded names [Definition:] local name [Definition:] namespace name [Definition:] NCName [XML Namespaces 1.1] NCName [XML Schema: Datatypes] Note: · · QName NCName [XML Namespaces 1.1] [Namespaces in XML 1.0] [Definition:] · · resolves to QName resolution (Schema Document) (§3.17.6.2) · · resolves to QName resolution (Instance) (§3.17.6.3) In each of the XML representation expositions in the following sections, an attribute is shown as having type QName Example <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xhtml="http://www.w3.org/1999/xhtml" xmlns="http://www.example.com" targetNamespace="http://www.example.com"> . . .
<xs:element name="elem1" type="Address"/>
<xs:element name="elem2" type="xhtml:blockquote"/>
<xs:attribute name="attr1" type="xsl:quantity"/> . . . </xs:schema> The first of these is most probably a local reference, i.e. a reference to a type definition corresponding to a <complexType> References to schema components across namespaces ( <import> ID The preferred way to refer to schema components is to use [XML Schema: Component Designators] xscd() [XPointer] Alternatively, references to specific element information items in the schema document can be interpreted as to their corresponding schema documents. This can be done using mechanisms supported by [XPointer] None as such. None as such. Schema Information Set Contribution: Schema Information Schema components provide a wealth of information about the basis of · · · · Accordingly, [Definition:] item isomorphic The · · PSVI Contributions for [schema information] A set of namespace schema information {target namespace} · · {target namespace} namespace schema information PSVI Contributions for [schema namespace] A namespace name or · · [schema components] A (possibly empty) set of schema component information items, each one an · · {target namespace} [schema namespace] · · [schema documents] A (possibly empty) set of schema document targetNamespace [schema namespace] targetNamespace · · <include> targetNamespace Assembling a schema for a single target namespace from multiple schema definition documents ( <include> PSVI Contributions for [document location] Either a URI reference, if available, otherwise · · [document] A document information item, if available, otherwise · · The [schema components] · · is must · · Schema Information Set Contribution: ID/IDREF Table In the · · ID/IDREF binding · · PSVI Contributions for [ID/IDREF table] A (possibly empty) set of ID/IDREF binding [Definition:] eligible item set all 1 its [validation context] · · 2 [schema actual value] · · 3 · · ID IDREF IDREFS · · · · Note: [schema actual value] · · default fixed may · · Note: · · ID/IDREF binding [ID/IDREF table] · · · · · · · · Each ID/IDREF binding PSVI Contributions for [id] The string identified above. [binding] A set consisting of every element information item for which all 1 its [validation context] · · 2 it has an attribute information item in its [attributes] [children] · · [id] ID/IDREF binding · · ID The net effect of the above is to have one entry for every string used as an id, whether by declaration or by reference, associated with those elements, if any, which actually purport to have that id. See Validation Root Valid (ID/IDREF) (§3.3.4.5) Note: ID/IDREF binding Validation Root Valid (ID/IDREF) (§3.3.4.5) All schemas (see Schemas as a Whole (§3.17) must Schema Component Constraint: Schema Properties Correct All must 1 The values of the properties of a schema are as described in the property tableau in The Schema Itself (§3.17.1) Missing Sub-components (§5.3) 2 None of the {type definitions} {attribute declarations} {element declarations} {attribute group definitions} {model group definitions} {notation declarations} {identity-constraint definitions} expanded name Schema Representation Constraint: QName resolution (Schema Document) For a · · all must 1 That component is a member of the value of the appropriate property of the schema which corresponds to the schema document within which the · · case 1.1 If then {type definitions} 1.2 If then {attribute declarations} 1.3 If then {element declarations} 1.4 If then {attribute group definitions} 1.5 If then {model group definitions} 1.6 If then {notation declarations} 1.7 If then {identity-constraint definitions} 2 The component's {name} · · · · 3 The component's {target namespace} · · · · 4 case 4.1 If · · · · · · then one 4.1.1 The <schema> · · targetNamespace [attribute] 4.1.2 The <schema> <import> namespace [attribute] 4.2 otherwise · · · · one 4.2.1 The · · targetNamespace [attribute] <schema> · · 4.2.2 The · · namespace [attribute] <import> <schema> 4.2.3 http://www.w3.org/2001/XMLSchema 4.2.4 http://www.w3.org/2001/XMLSchema-instance As the discussion above at Schema Component Details (§3) · · · · must Validation Rule: QName resolution (Instance) A pair of a local name and a namespace name (or · · · · · · case must 1 If then {type definitions} 2 If then {attribute declarations} 3 If then {element declarations} 4 If then {attribute group definitions} 5 If then {model group definitions} 6 If then {notation declarations} {name} {target namespace} This chapter defines the mechanisms by which this specification establishes the necessary precondition for · · Conformance (§2.4) Schemas and Schema-validity Assessment (§5) · · The · · Schema representation: the connections between XML representations and schema components, including the relationships between namespaces and schema components; XSD web-interoperability guidelines: connections from instance to schema (or schema document) and from schema document to schema (or schema document) for the WWW. Layer 1 specifies the manner in which a schema composed of schema components can be applied to in the · · <schema> The fundamental purpose of the · · · · · · · · not · · As specified above, each schema component is associated directly or indirectly with a target namespace, or explicitly with no namespace. In the case of multi-namespace documents, components for more than one target namespace will co-exist in a schema. Processors have the option to assemble (and perhaps to optimize or pre-compile) the entire schema prior to the start of an · · The processor succeed in locating the · · · · · · no definition or declaration changes once it has been established; if the processor chooses to acquire declarations and definitions dynamically, that there be no side effects of such dynamic acquisition that would cause the results of · · Note: · · <schema> may The obligation of a schema-aware processor as far as the · · · · Assessing Schema-Validity (§5.2) · · · · Although · · may must · · same · · 4.2.1 Basic concepts of schema construction and composition Conditional inclusion Assembling a schema for a single target namespace from multiple schema definition documents (<include>) Including modified component definitions (<redefine>) Overriding component definitions (<override>) References to schema components across namespaces (<import>) Licensing References to Components Across Namespaces Providing Hints for Imported Schema Document Locations The sub-sections of Schema Component Details (§3) Note: · · Conformance (§2.4) Note: When a schema is assembled from multiple sources, those sources can include both · · · · · · · · The sections that follow appeal often to the following concepts. The pre-processing of a schema document before attempting to map its contents into components, or the pre-processing of a set of components before they take their final form among the components of a schema being constructed. The following sections define several forms of pre-processing, including: conditional-inclusion pre-processing, chameleon pre-processing, redefinition pre-processing, and override pre-processing. Conditional-inclusion pre-processing is always performed first; the sequence in which other forms of pre-processing are applied varies; details are given below. The process of applying to a schema document the filtering described in section Conditional inclusion (§4.2.2) · · D D ci D The immediate components of a · · D [children] immed D The <include> <redefine> <override> <import> The schema corresponding to a given · · D · · · immed D · D schema D The target namespace specified in a schema document D tns D The application, to a schema document D Transformation for Chameleon Inclusion (§F.1) N N chameleon N D The application, to a schema document D <override> E Transformation for xs:override override E D The application, to a schema S <override> E Including modified component definitions ( <redefine> redefine E S Note: The xsi:schemaLocation xsi:noNamespaceSchemaLocation hints may The schemaLocation <import> may The schemaLocation <include> <override> <redefine> must <redefine> must In all cases, the use of the attribute in a document indicates the existence of a suitable schema document at the location indicated. This is stated explicitly below for some attributes, but not for all; where not stated explicitly, the inference follows implicitly from other rules. Whenever a conforming XSD processor reads a · · Every element in the · · vc:minVersion vc:maxVersion vc:typeAvailable vc:typeUnavailable vc:facetAvailable vc:facetUnavailable [attributes] Where they appear, the attributes vc:minVersion vc:maxVersion xs:decimal · · V V If V vc:minVersion V vc:maxVersion vc:minVersion vc:maxVersion vc:minVersion V vc:maxVersion Where they appear, the attributes vc:typeAvailable vc:typeUnavailable list of xs:QName · · · · vc:facetAvailable vc:facetUnavailable If an element in a schema document has any of the following: vc:typeAvailable T · · T not expanded name · · vc:typeUnavailable T · · T expanded name · · vc:facetAvailable F · · F expanded name vc:facetUnavailable F · · F expanded name Note: vc:typeAvailable · · vc:typeAvailable expanded name Note: expanded names [XML Schema: Datatypes] expanded name · · [XML Schema: Datatypes] Note: expanded names · · expanded names xs:pattern pattern Note: · · vc:typeAvailable vc:typeAvailable="" not · · vc:typeUnavailable vc:facetAvailable vc:facetUnavailable The pre-processing of a schema document S1 S2 S1 S1 S2 S2 ci S1 <schema> S1 S2 S1 targetNamespace vc:minVersion vc:maxVersion [attributes] [children] S2 S1 Note: S1 S1 S2 Except where conditional-inclusion pre-processing is explicitly mentioned, references to · · Example Suppose some future version of XSD (say, version 3.2) introduces a new form of element declaration. A schema author might wish to exploit that new form of declaration if possible, but wish also to ensure that the schema document can be handled successfully by a processor written for XSD 1.1. In such a case, a schema document of the following form would be handled correctly by a conforming XSD 1.1 processor: <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:vc="http://www.w3.org/2007/XMLSchema-versioning">
<xs:element name="e" vc:minVersion="3.2"> <!--* declaration suitable for 3.2 * and later processors *--> </xs:element> <xs:element name="e" vc:minVersion="1.1" vc:maxVersion="3.2"> <!--* declaration suitable for processors * supporting versions 1.1 through versions * up to (but not including) 3.2 *--> </xs:element> ... </xs:schema> Even though the schema document as shown has two element declarations for element e 2 Schema Properties Correct (§3.17.6.1) Note that the semantics of the vc:maxVersion Example Suppose that a processor supports an · · xpath_expression http://example.org/extension_types <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:vc="http://www.w3.org/2007/XMLSchema-versioning" xmlns:tns="http://example.org/extension_types" targetNamespace="http://example.org/extension_types" >
<xs:element vc:typeAvailable="tns:xpath_expression" name="e" type="tns:xpath_expression" /> <xs:element vc:typeUnavailable="tns:xpath_expression" name="e" type="string" /> </xs:schema> The effect of conditional inclusion is to include the first declaration for e <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:vc="http://www.w3.org/2007/XMLSchema-versioning" xmlns:tns="http://example.org/extension_types" targetNamespace="http://example.org/extension_types" >
<xs:element vc:typeAvailable="tns:xpath_expression" name="e" type="tns:xpath_expression" /> </xs:schema> A processor which does not support type "tns:xpath_expression", by contrast, will use the other declaration for e <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:vc="http://www.w3.org/2007/XMLSchema-versioning" xmlns:tns="http://example.org/extension_types" targetNamespace="http://example.org/extension_types" >
<xs:element vc:typeUnavailable="tns:xpath_expression" name="e" type="string" /> </xs:schema> Schema Representation Constraint: Conditional Inclusion Constraints Whenever the attribute vc:minVersion vc:maxVersion · · · · must · · xs:decimal String Valid (§3.16.4) Whenever any of the attributes vc:typeAvailable vc:typeUnavailable vc:facetAvailable vc:facetUnavailable · · · · must · · {variety} list {item type definition} xs:QName String Valid (§3.16.4) Any attribute from the vc: · · should vc:minVersion vc:maxVersion vc:typeAvailable vc:typeUnavailable vc:facetAvailable vc:facetUnavailable Note: vc: · · should must <include> Schema components for a single target namespace can be assembled from several · · <schema> XML Representation Summary include <include ID schemaLocation anyURI {any attributes with non-schema namespace . . .} Content: annotation A <schema> may <include> schemaLocation · · <schema> If two <include> If a · · D 1 <include> schema D 1 immed D 1 schema D 2 · · D 2 <include> D 1 D 2 must targetNamespace D 1 targetNamespace schema D 1 schema D 2 schema chameleon tns D 1 D 2 D 2 tns D 1 Schema Representation Constraint: Inclusion Constraints and Semantics In addition to the conditions imposed on <include> all 1 · · schemaLocation [attribute] one or more 1.1 It resolves to (a fragment of) a resource which is an XML document (of type application/xml text/xml <schema> 1.2 It resolves to a <schema> <include> <schema> D2 <include> <schema> D1 2 One must 2.1 D2 targetNamespace [attribute] · · · · targetNamespace [attribute] D1 must [attribute] 2.2 Neither D2 D1 targetNamespace [attribute] 2.3 D2 targetNamespace [attribute] D1 2.4 D2 · · schemaLocation [attribute] 3 The appropriate case must 3.1 If 2.1 2.2 then all 3.1.1 D2 S2 3.1.2 The schema corresponding to D1 [children] · · S2 Schema 3.2 If 2.3 then all 3.2.1 Let D2′ <schema> D2 Transformation for Chameleon Inclusion (§F.1) D2′ S2 Note: Transformation for Chameleon Inclusion (§F.1) targetNamespace [attribute] D2 targetNamespace [attribute] D1 · · targetNamespace [attribute] [XSLT 2.0] Transformation for Chameleon Inclusion (§F.1) may 3.2.2 The schema corresponding to D1 [children] · · S2 Schema Note: A B B C A targetNamespace [attribute] B C A B' B' C' B' C' B C targetNamespace [attribute] A Note: D2′ D2 3.2.1 D2 is D2′ Note: D2 D1 3.2 1 Import Constraints and Semantics (§4.2.6.2) It is not · · schemaLocation [attribute] must not is · · As discussed in Missing Sub-components (§5.3) · · · · must · · · · · · · · <include> must 3.2 Note: <include> 2 Schema Properties Correct (§3.17.6.1) <include> If there is a sequence of schema documents S1 S2 Sn <include> E1 E2 En S i E i E i i n S i En S1 <include> S1 Sn S1 Sn <include> S1 Note: <include> <redefine> Note: · · In order to provide some support for evolution and versioning, it is possible to incorporate components corresponding to a schema document with modifications XML Representation Summary redefine <redefine ID schemaLocation anyURI {any attributes with non-schema namespace . . .} Content: annotation simpleType complexType group attributeGroup A <schema> may <redefine> schemaLocation · · <schema> If a schema document D 1 <redefine> E D 2 schema D 1 immed D 1 redefine E schema D 2 D 2 <redefine> D 1 must tns D 1 tns D 2 tns D 2 · · schema D 1 redefine E schema D 2 redefine E schema chameleon tns D 1 D 2 D 2 chameleon tns D 1 D 2 D 2 tns D 1 The definitions within the <redefine> <redefine> in terms of themselves Type definitions must Attribute group definitions and model group definitions must <redefine> <redefine> This mechanism is intended to provide a declarative and modular approach to schema modification, with functionality no different except in scope from what would be achieved by wholesale text copying and redefinition by editing. In particular redefining a type is not guaranteed to be side-effect free: it can have unexpected impacts on other type definitions which are based on the redefined one, even to the extent that some such definitions become ill-formed. Note: Example v1.xsd: <xs:complexType name="personName"> <xs:sequence> <xs:element name="title" minOccurs="0"/> <xs:element name="forename" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType>
<xs:element name="addressee" type="personName"/>
v2.xsd: <xs:redefine schemaLocation="v1.xsd"> <xs:complexType name="personName"> <xs:complexContent> <xs:extension base="personName"> <xs:sequence> <xs:element name="generation" minOccurs="0"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> </xs:redefine>
<xs:element name="author" type="personName"/> The schema corresponding to v2.xsd v1.xsd personName personName may generation author addressee Schema Representation Constraint: Redefinition Constraints and Semantics In addition to the conditions imposed on <redefine> all 1 If there are any element information items among the [children] <annotation> · · schemaLocation [attribute] must 2 · · schemaLocation [attribute] one or more 2.1 it resolves to (a fragment of) a resource which is an XML document (see clause 1.1 Inclusion Constraints and Semantics (§4.2.3) <schema> 2.2 It resolves to a <schema> <redefine> <schema> D2 <redefine> <schema> D1 3 One must 3.1 D2 targetNamespace [attribute] · · · · targetNamespace [attribute] D1 must [attribute] 3.2 Neither D2 D1 targetNamespace [attribute] 3.3 D2 targetNamespace [attribute] D1 4 The appropriate case must 4.1 If 3.1 3.2 then 4.1.1 D2 S2 4.1.2 The schema corresponding to D1 [children] · · S2 Individual Component Redefinition (§4.2.4) Schema S2 4.2 If 3.3 then 4.2.1 Let D2′ <schema> D2 Transformation for Chameleon Inclusion (§F.1) D2′ S2 4.2.2 The schema corresponding to D1 [children] · · S2 Individual Component Redefinition (§4.2.4) Note: D2′ D2 4.2.1 D2 is D2′ 5 Within the [children] <simpleType> must <restriction> [children] <complexType> must restriction extension [children] · · base [attribute] must · · name 6 Within the [children] <group> case must 6.1 If <group> · · ref [attribute] · · name <group> <element> then all 6.1.1 It has exactly one such group. 6.1.2 The · · minOccurs maxOccurs [attribute] 1 · · 6.2 If then all 6.2.1 The · · name · · S2 6.2.2 {model group} XML Representation of Model Group Definition Schema Components (§3.7.2) S2 7 Within the [children] <attributeGroup> case must 7.1 If <attributeGroup> · · ref [attribute] · · name then 7.2 If then all 7.2.1 The · · name · · S2 7.2.2 The {attribute uses} {attribute wildcard} XML Representation of Attribute Group Definition Schema Components (§3.6.2) {attribute uses} {attribute wildcard} Complex Type Definition {attribute uses} {attribute wildcard} S2 {attribute uses} {attribute wildcard} {base type definition} 3 Derivation Valid (Restriction, Complex) (§3.4.6.3) Note: 7.2 {attribute uses} <attribute> [children] <redefine> <attributeGroup> <redefine> {attribute wildcard} <anyAttribute> Schema Representation Constraint: Individual Component Redefinition Corresponding to each non- <annotation> [children] <redefine> <redefine> 1 The <simpleType> <complexType> [children] 1.1 One component which corresponds to the top-level definition item with the same name <redefine> Schema Component Details (§3) {name} · · {context} 1.2 1.2 One component which corresponds to the information item itself, as defined in Schema Component Details (§3) {base type definition} 1.1 This pairing ensures the coherence constraints on type definitions are respected, while at the same time achieving the desired effect, namely that references to names of redefined components in both the <redefine> <redefine> · · 2 The <group> <attributeGroup> [children] Schema Component Details (§3) ref [attribute] · · name · · S2 In all cases there must <redefine> Note: <redefine> 2 Schema Properties Correct (§3.17.6.1) <redefine> <override> The <redefine> Including modified component definitions ( <redefine> <redefine> <redefine> · · <override> Note: <override> · · · · XML Representation Summary override <override ID schemaLocation anyURI {any attributes with non-schema namespace . . .} Content: annotation simpleType complexType group attributeGroup element attribute notation A <schema> may <override> schemaLocation · · <schema> If a schema document D new <override> E D old schema D new immed D new schema override E D old D old must tns D old tns D new tns D old · · schema D new schema override E D old schema override E chameleon tns D new D old D old tns D new chameleon tns D new D old Note: include override override E D E D D [XPath 2.0] fn:deep-equal override E D E The children of the <override> may · · [children] <schema> <redefine> <override> · · <override> [Definition:] target set <override> E all 1 The schema document identified by the schemaLocation E 2 The schema document identified by the schemaLocation <override> · · E 3 The schema document identified by the schemaLocation <include> · · E target set E Note: · · <override> S1 S2 S1 <include> S2 S1 S2 S1 <override> S2 <import> <redefine> <include> <override> Source declarations not present in the target set of E <redefine> <override> Note: Transformation for xs:override <override> <include> <override> <override> <override> <override> <include> Transformation for xs:override Note: not D <override> E · · E If applying the override transformation specified in Transformation for xs:override D E D [children] D <redefine> <override> D [children] E [children] E <include> Assembling a schema for a single target namespace from multiple schema definition documents ( <include> If applying the override transformation to D E D · · E The definitions within the <override> not As this mechanism is very similar to <redefine> <override> Including modified component definitions ( <redefine> Example v1.xsd: <xs:complexType name="personName"> <xs:sequence> <xs:element name="firstName"/> <xs:element name="lastName"/> </xs:sequence> </xs:complexType>
<xs:element name="addressee" type="personName"/>
v2.xsd: <xs:override schemaLocation="v1.xsd"> <xs:complexType name="personName"> <xs:sequence> <xs:element name="givenName"/> <xs:element name="surname"/> </xs:sequence> </xs:complexType> </xs:override>
<xs:element name="author" type="personName"/> The schema corresponding to v1.xsd personName firstName lastName v2.xsd personName personName givenName surname author addressee Schema Representation Constraint: Override Constraints and Semantics In addition to the conditions imposed on <override> all 1 If the · · schemaLocation [attribute] one or more 1.1 It resolves to (a fragment of) a resource which is an XML document (see clause 1.1 Inclusion Constraints and Semantics (§4.2.3) <schema> 1.2 It resolves to a <schema> <schema> D old <schema> D new 2 One must 2.1 D old targetNamespace [attribute] · · · · targetNamespace [attribute] D new must [attribute] 2.2 Neither D old D new targetNamespace [attribute] 2.3 D old targetNamespace [attribute] D new 3 The appropriate case must 3.1 If 2.1 2.2 then 3.1.1 Let D old <schema> D old Transformation for xs:override D old S old 3.1.2 The <override> D new D old <include> D old Assembling a schema for a single target namespace from multiple schema definition documents ( <include> Note: <override> D new <include> Note: D new [children] · · S old Schema S old Note: A E B A E C B E schema C 3.1.2.1 First, the override of B C B B <override> A E C 3.1.2.2 Then, the override of A B B 3.1.2.3 The resulting version of A E C B C 3.1.2.4 The resulting schema contains the version of E C 3.2 If 2.3 then 3.2.1 Let D old <schema> D old Transformation for Chameleon Inclusion (§F.1) Transformation for xs:override D old S2 3.2.2 The <override> D new D old <include> D old Assembling a schema for a single target namespace from multiple schema definition documents ( <include> Note: Transformation for xs:override D old D old D old Transformation for xs:override [XSLT 2.0] Note: D old D old D old is D old Note: <override> elementFormDefault attributeFormDefault blockDefault finalDefault <override> D new D old <override> Note: <redefine> <override> Note: 2 Schema Properties Correct (§3.17.6.1) Note: Inclusion Constraints and Semantics (§4.2.3) 3.1.2 3.2.2 Including modified component definitions ( <redefine> References to schema components across namespaces ( <import> · · <import> As described in XSD Abstract Data Model (§2.2) <schema> targetNamespace may · · · · Note: [XSD 1.0 2E] <import> schemaLocation <import> <import> XML Representation Summary import <import ID anyURI anyURI {any attributes with non-schema namespace . . .} Content: annotation The <import> · · targetNamespace At least two conditions must be satisfied for a reference to be made to a foreign component: (1) there must be a means of addressing such foreign components, and (2) there must be a signal to schema-aware processors that a schema document contains such references. The namespace mechanisms defined by [XML Namespaces 1.1] schemaLocation <import> Terminology of schema construction (§C.2) <import> · · targetNamespace Note: <documentation> If the schema document does refer to components in the XHTML namespace, then the schema document must <xs:import namespace="http://www.w3.org/1999/xhtml"/> schemaLocation No import is needed in order to use XHTML to mark up the text appearing within <documentation> <documentation> <appinfo> <documentation> Schema for Schema Documents (Structures) (normative) (§A) Schema for Schema Documents (Structures) (normative) (§A) Note: If each use of a foreign namespace within a schema document implicitly imported that namespace into the schema being constructed, then using XHTML for documentation would automatically result in the inclusion of XHTML components in the schema described by the schema document. The same logic would also apply to any vocabulary used for documentation. Such automatic import would lead processors to expend unnecessary extra effort to find components for the documentation namespace and would in many cases result in a schema which is not the one intended or desired by the schema author. Additionally, the requirement that the <import> The · · namespace [attribute] may It is a consequence of rules defined elsewhere that if references to components in a given namespace N S S must <import> N 4 QName resolution (Schema Document) (§3.17.6.2) QName resolution (Schema Document) (§3.17.6.2) not The Mapping between XML Representations and Components (§3.1.3) not Missing Sub-components (§5.3) Note that components to be imported need not be in the form of a · · schemaLocation schemaLocation Example The same namespace can be used both as the namespace of elements and attributes appearing in the schema document, and in the course of defining schema components in terms of foreign components. The import in this example is necessary because there is a reference to the element component xhtml:p <documentation> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xhtml="http://www.w3.org/1999/xhtml" targetNamespace="uri:mywork" xmlns:my="uri:mywork">
<xs:import namespace="http://www.w3.org/1999/xhtml"/>
<xs:annotation> <xs:documentation> <!--* The XHTML 'p' element below requires us to define a prefix for the XHTML namespace, but it does NOT require us to import the XHTML namespace into the schema. The use of XHTML (or other) markup here is allowed by the lax wildcard in the schema for schema documents. *--> <xhtml:p>[Some documentation for my schema]</xhtml:p> </xs:documentation> </xs:annotation>
. . .
<xs:complexType name="myType"> <xs:sequence> <xs:element ref="xhtml:p" minOccurs="0"/> </xs:sequence> . . . </xs:complexType>
<xs:element name="myElt" type="my:myType"/> </xs:schema> Since component references are given as · · either or The · · schemaLocation <import> · · schemaLocation [attribute] Layer 3: Schema Document Access and Web-interoperability (§4.3) schemaLocation must · · <import> Conformance profiles may further restrict the use of the schemaLocation Note: namespace schemaLocation [attribute] <import/> Schema Representation Constraint: Import Constraints and Semantics In addition to the conditions imposed on <import> all 1 case must 1.1 If namespace [attribute] then · · · · <schema> targetNamespace [attribute] 1.2 If namespace [attribute] then <schema> targetNamespace [attribute] 2 · · schemaLocation namespace [attributes] one must 2.1 The result is (a fragment of) a resource which is an XML document (see clause 1.1 Inclusion Constraints and Semantics (§4.2.3) <schema> 2.2 The result is a <schema> <schema> D2 S2 3 If D2 2.1 2.2 case must 3.1 If namespace [attribute] then · · · · targetNamespace [attribute] D2 3.2 If namespace [attribute] then D2 targetNamespace [attribute] It is not is 2 · · The · · {type definitions} {attribute declarations} {element declarations} {attribute group definitions} {model group definitions} {notation declarations} <schema> <import> must [children] <import> 2 · · · · S2 Schema S2 Note: <import> 2 Schema Properties Correct (§3.17.6.1) <import> schemaLocation [attribute] <import> · · schemaLocation schemaLocation 4.3.1 Standards for representation of schemas and retrieval of schema documents on the Web How schema definitions are located on the Web Layers 1 and 2 provide a framework for · · For interoperability, serialized · · should must 1.1 Inclusion Constraints and Semantics (§4.2.3) <schema> Note: <schema> <schema> [XPointer] Note: · · Accept application/xml, text/xml; q=0.9, */* As described in Layer 1: Summary of the Schema-validity Assessment Core (§4.1) · · Note: Layer 2: Schema Documents, Namespaces and Composition (§4.2) · · Processors on the Web are free to undertake · · Assessing Schema-Validity (§5.2) · · must unless directed otherwise by the user, · · unless directed otherwise by the user, the processor is required to construct a schema corresponding to a schema document whose targetNamespace · · The composition of the complete schema for use in · · Layer 2: Schema Documents, Namespaces and Composition (§4.2) Schemas are represented on the Web in the form specified above in Standards for representation of schemas and retrieval of schema documents on the Web (§4.3.1) The author of a document uses namespace declarations to indicate the intended interpretation of names appearing therein; it is possible but not guaranteed that a schema is retrievable via the namespace name. Accordingly whether a processor's default behavior is or is not to attempt such dereferencing, it must Note: is On the other hand, in case a document author (human or not) created a document with a particular schema in view, and warrants that some or all of the document conforms to that schema, the xsi:schemaLocation xsi:noNamespaceSchemaLocation [attributes] targetNamespace [attribute] Processors may · · xsi:schemaLocation xsi:noNamespaceSchemaLocation [attributes] should not · · Note: When systems rely on an input document being schema-valid with respect to a particular agreed-upon schema, it is important that they be able to have complete control over the choice of schema used in assessment and in particular that they be able to instruct the processor not schemaLocation In other cases the purpose of assessment may be not to enforce a prior agreement between data source and consumer, but to annotate the input with type definitions and other useful information from the · · schemaLocation Users who need to exert control over the choice of schema can normally be expected to be aware of the requirement; conversely, users unaware of the issue will typically be those who are not relying on the use of a particular schema to enforce a specific agreement with the data source. Casual users will often benefit from a default behavior of following schemaLocation Useful guidance on how to present this and other questions to end users may be found in the W3C's User Agent Accessibility Guidelines [UAAG 1.0] [UAAG 2.0] When schema location values (i.e. schemaLocation <include> <redefine> <override> <import> xsi:schemaLocation xsi:noNamespaceSchemaLocation [base URI] [owner element] must According to the rules of Layer 1: Summary of the Schema-validity Assessment Core (§4.1) may · · · · Example Multiple schema bindings can be declared using a single attribute. For example consider a stylesheet: <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:xhtml="http://www.w3.org/1999/xhtml" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.w3.org/1999/XSL/Transform http://www.w3.org/1999/XSL/Transform.xsd http://www.w3.org/1999/xhtml http://www.w3.org/1999/xhtml.xsd"> The namespace names used in schemaLocation Improved or alternative conventions for Web interoperability can be standardized in the future without reopening this specification. For example, the W3C is currently considering initiatives to standardize the packaging of resources relating to particular documents and/or namespaces: this would be an addition to the mechanisms described here for layer 3. This architecture also facilitates innovation at layer 2: for example, it would be possible in the future to define an additional standard for the representation of schema components which allowed e.g. type definitions to be specified piece by piece, rather than all at once. The architecture of schema-aware processing allows for a rich characterization of XML documents: schema validity is not a binary predicate. This specification distinguishes between errors in schema construction and structure, on the one hand, and schema validation outcomes, on the other. Before · · · · should Terminology of schema construction (§C.2) · · · · xsi:schemaLocation xsi:noNamespaceSchemaLocation [attributes] It is an error if a schema and all the components which are the value of any of its properties, recursively, fail to satisfy all the relevant Constraints on Schemas set out in the subsections of Schema Component Details (§3) If a schema is derived from one or more schema documents (that is, one or more <schema> Schema Component Details (§3) Schemas and Namespaces: Access and Composition (§4) Conditional inclusion (§4.2.2) It is an error if any such schema document would not be fully valid with respect to a schema corresponding to the Schema for Schema Documents (Structures) (normative) (§A) <schema> [validation attempted] full partial [validity] valid It is an error if any such schema document is or contains any element information items which violate any of the relevant Schema Representation Constraints set out in Schema Representation Constraints (§B.3) The cases described above are the only types of error which this specification defines. With respect to the processes of the checking of schema structure and the construction of schemas corresponding to schema documents, this specification imposes no restrictions on processors in the presence of errors, beyond the requirement that if there are errors in a schema, or in one or more schema documents used in constructing a schema, then a conforming processor must · · With a schema which satisfies the conditions expressed in Errors in Schema Construction and Structure (§5.1) · · may type-driven validation The user or application identifies a type definition from among the type definitions of the schema. If the · · Schema-Validity Assessment (Element) (§3.3.4.6) · · String Valid (§3.16.4) Note: should The user or application identifies an element declaration from among the element declarations of the schema and the item is validated as described in Schema-Validity Assessment (Element) (§3.3.4.6) · · Note: should attribute-driven validation The user or application identifies an attribute declaration from among the attribute declarations of the schema and the item is validated as described in Schema-Validity Assessment (Attribute) (§3.2.4.3) · · lax wildcard validation The processor starts from Schema-Validity Assessment (Element) (§3.3.4.6) · · xsi:type · · · · Note: lax The processor starts from Schema-Validity Assessment (Element) (§3.3.4.6) · · xsi:type · · · · Note: · · In typical cases strict wildcard validation will be performed when the invoking process expects the · · · · The name for this method of invocation reflects the fact that it is analogous to the validation of an element information item which matches a strict Note: [XML Schema: Component Designators] [Definition:] · · validation root The outcome of schema-validity assessment will be manifest in the [validation attempted] [validity] · · · · [attributes] [children] Assessment Outcome (Element) (§3.3.5.1) Assessment Outcome (Attribute) (§3.2.5.1) Note that every element and attribute information item participating in the · · [validation context] · · Note: root · · element-driven validation Note: · · · · · · · · · · [validation attempted] none · · · · [children] [attributes] · · · · · · [children] [attributes] At the beginning of Schema Component Details (§3) QNames · · QNames · · If at any time during · · · · · · · · In the case of attribute information items, the effect is as if clause 1 Attribute Locally Valid (§3.2.4.1) In the case of element information items, the effect is as if clause 1 Element Locally Valid (Element) (§3.3.4.3) In the case of element information items, processors must · · Because of the value specification for [validation attempted] Assessment Outcome (Element) (§3.3.5.1) [validation attempted] full References in a Simple Type Definition unknown unknown · · · · · · Schema-aware processors are responsible for processing XML documents, schemas and schema documents, as appropriate given the level of conformance (as defined in Conformance (§2.4) The XML representation of the schema for schema documents is presented here as a normative part of the specification, and as an illustrative example of how the XML Schema Definition Language can define itself using its own constructs. The names of XSD types, elements, attributes and groups defined here are evocative of their purpose, but are occasionally verbose. There is some annotation in comments, but a fuller annotation will require the use of embedded documentation facilities or a hyperlinked external annotation for which tools are not yet readily available. Like any other XML document, schema documents may carry XML and document type declarations. An XML declaration and a document type declaration are provided here for convenience. Since this schema document describes the XSD language, the targetNamespace schema Schema documents conforming to this specification may be in XML 1.0 or XML 1.1. Conforming implementations may accept input in XML 1.0 or XML 1.1 or both. See Dependencies on Other Specifications (§1.4) Independent copies of this material are available in an undated (mutable) version at http://www.w3.org/2009/XMLSchema/XMLSchema.xsd http://www.w3.org/2012/04/XMLSchema.xsd Schema for schema documents <?xml version='1.0'?>
<!DOCTYPE xs:schema PUBLIC "-//W3C//DTD XSD 1.1//EN" "XMLSchema.dtd" [
<!-- provide ID type information even for parsers which only read the internal subset --> <!ATTLIST xs:schema id ID #IMPLIED> <!ATTLIST xs:complexType id ID #IMPLIED> <!ATTLIST xs:complexContent id ID #IMPLIED> <!ATTLIST xs:simpleContent id ID #IMPLIED> <!ATTLIST xs:extension id ID #IMPLIED> <!ATTLIST xs:element id ID #IMPLIED> <!ATTLIST xs:group id ID #IMPLIED> <!ATTLIST xs:all id ID #IMPLIED> <!ATTLIST xs:choice id ID #IMPLIED> <!ATTLIST xs:sequence id ID #IMPLIED> <!ATTLIST xs:any id ID #IMPLIED> <!ATTLIST xs:anyAttribute id ID #IMPLIED> <!ATTLIST xs:attribute id ID #IMPLIED> <!ATTLIST xs:attributeGroup id ID #IMPLIED> <!ATTLIST xs:unique id ID #IMPLIED> <!ATTLIST xs:key id ID #IMPLIED> <!ATTLIST xs:keyref id ID #IMPLIED> <!ATTLIST xs:selector id ID #IMPLIED> <!ATTLIST xs:field id ID #IMPLIED> <!ATTLIST xs:assert id ID #IMPLIED> <!ATTLIST xs:include id ID #IMPLIED> <!ATTLIST xs:import id ID #IMPLIED> <!ATTLIST xs:redefine id ID #IMPLIED> <!ATTLIST xs:override id ID #IMPLIED> <!ATTLIST xs:notation id ID #IMPLIED> ]>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" xml:lang="EN" targetNamespace="http://www.w3.org/2001/XMLSchema" version="structures.xsd (rec-20120405)"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/structures.html"> The schema corresponding to this document is normative, with respect to the syntactic constraints it expresses in the XML Schema Definition Language. The documentation (within 'documentation' elements) below, is not normative, but rather highlights important aspects of the W3C Recommendation of which this is a part.
See below (at the bottom of this document) for information about the revision and namespace-versioning policy governing this schema document.
</xs:documentation> </xs:annotation> <xs:annotation> <xs:documentation> The simpleType element and all of its members are defined in datatypes.xsd</xs:documentation> </xs:annotation> <xs:include schemaLocation="datatypes.xsd"/> <xs:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/xml.xsd"> <xs:annotation> <xs:documentation> Get access to the xml: attribute groups for xml:lang as declared on 'schema' and 'documentation' below </xs:documentation> </xs:annotation> </xs:import> <xs:complexType name="openAttrs"> <xs:annotation> <xs:documentation> This type is extended by almost all schema types to allow attributes from other namespaces to be added to user schemas. </xs:documentation> </xs:annotation> <xs:complexContent> <xs:restriction base="xs:anyType"> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:complexType name="annotated"> <xs:annotation> <xs:documentation> This type is extended by all types which allow annotation other than <schema> itself </xs:documentation> </xs:annotation> <xs:complexContent> <xs:extension base="xs:openAttrs"> <xs:sequence> <xs:element ref="xs:annotation" minOccurs="0"/> </xs:sequence> <xs:attribute name="id" type="xs:ID"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:group name="composition"> <xs:choice> <xs:element ref="xs:include"/> <xs:element ref="xs:import"/> <xs:element ref="xs:redefine"/> <xs:element ref="xs:override"/> <xs:element ref="xs:annotation"/> </xs:choice> </xs:group> <xs:group name="schemaTop"> <xs:annotation> <xs:documentation> This group is for the elements which occur freely at the top level of schemas. All of their types are based on the "annotated" type by extension.</xs:documentation> </xs:annotation> <xs:choice> <xs:group ref="xs:redefinable"/> <xs:element ref="xs:element"/> <xs:element ref="xs:attribute"/> <xs:element ref="xs:notation"/> </xs:choice> </xs:group> <xs:group name="redefinable"> <xs:annotation> <xs:documentation> This group is for the elements which can self-redefine (see <redefine> below).</xs:documentation> </xs:annotation> <xs:choice> <xs:element ref="xs:simpleType"/> <xs:element ref="xs:complexType"/> <xs:element ref="xs:group"/> <xs:element ref="xs:attributeGroup"/> </xs:choice> </xs:group> <xs:simpleType name="formChoice"> <xs:annotation> <xs:documentation> A utility type, not for public use</xs:documentation> </xs:annotation> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="qualified"/> <xs:enumeration value="unqualified"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="reducedDerivationControl"> <xs:annotation> <xs:documentation> A utility type, not for public use</xs:documentation> </xs:annotation> <xs:restriction base="xs:derivationControl"> <xs:enumeration value="extension"/> <xs:enumeration value="restriction"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="derivationSet"> <xs:annotation> <xs:documentation> A utility type, not for public use</xs:documentation> <xs:documentation> #all or (possibly empty) subset of {extension, restriction}</xs:documentation> </xs:annotation> <xs:union> <xs:simpleType> <xs:restriction base="xs:token"> <xs:enumeration value="#all"/> </xs:restriction> </xs:simpleType> <xs:simpleType> <xs:list itemType="xs:reducedDerivationControl"/> </xs:simpleType> </xs:union> </xs:simpleType> <xs:simpleType name="typeDerivationControl"> <xs:annotation> <xs:documentation> A utility type, not for public use</xs:documentation> </xs:annotation> <xs:restriction base="xs:derivationControl"> <xs:enumeration value="extension"/> <xs:enumeration value="restriction"/> <xs:enumeration value="list"/> <xs:enumeration value="union"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="fullDerivationSet"> <xs:annotation> <xs:documentation> A utility type, not for public use</xs:documentation> <xs:documentation> #all or (possibly empty) subset of {extension, restriction, list, union}</xs:documentation> </xs:annotation> <xs:union> <xs:simpleType> <xs:restriction base="xs:token"> <xs:enumeration value="#all"/> </xs:restriction> </xs:simpleType> <xs:simpleType> <xs:list itemType="xs:typeDerivationControl"/> </xs:simpleType> </xs:union> </xs:simpleType> <xs:element name="schema" id="schema"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/structures.html#element-schema"/> </xs:annotation> <xs:complexType> <xs:complexContent> <xs:extension base="xs:openAttrs"> <xs:sequence> <xs:group ref="xs:composition" minOccurs="0" maxOccurs="unbounded"/> <xs:sequence minOccurs="0"> <xs:element ref="xs:defaultOpenContent"/> <xs:element ref="xs:annotation" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:sequence minOccurs="0" maxOccurs="unbounded"> <xs:group ref="xs:schemaTop"/> <xs:element ref="xs:annotation" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:sequence> <xs:attribute name="targetNamespace" type="xs:anyURI"/> <xs:attribute name="version" type="xs:token"/> <xs:attribute name="finalDefault" type="xs:fullDerivationSet" default="" use="optional"/> <xs:attribute name="blockDefault" type="xs:blockSet" default="" use="optional"/> <xs:attribute name="attributeFormDefault" type="xs:formChoice" default="unqualified" use="optional"/> <xs:attribute name="elementFormDefault" type="xs:formChoice" default="unqualified" use="optional"/> <xs:attribute name="defaultAttributes" type="xs:QName"/> <xs:attribute name="xpathDefaultNamespace" type="xs:xpathDefaultNamespace" default="##local" use="optional"/> <xs:attribute name="id" type="xs:ID"/> <xs:attribute ref="xml:lang"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:key name="element"> <xs:selector xpath="xs:element"/> <xs:field xpath="@name"/> </xs:key> <xs:key name="attribute"> <xs:selector xpath="xs:attribute"/> <xs:field xpath="@name"/> </xs:key> <xs:key name="type"> <xs:selector xpath="xs:complexType|xs:simpleType"/> <xs:field xpath="@name"/> </xs:key> <xs:key name="group"> <xs:selector xpath="xs:group"/> <xs:field xpath="@name"/> </xs:key> <xs:key name="attributeGroup"> <xs:selector xpath="xs:attributeGroup"/> <xs:field xpath="@name"/> </xs:key> <xs:key name="notation"> <xs:selector xpath="xs:notation"/> <xs:field xpath="@name"/> </xs:key> <xs:key name="identityConstraint"> <xs:selector xpath=".//xs:key|.//xs:unique|.//xs:keyref"/> <xs:field xpath="@name"/> </xs:key> </xs:element> <xs:simpleType name="allNNI"> <xs:annotation> <xs:documentation> for maxOccurs</xs:documentation> </xs:annotation> <xs:union memberTypes="xs:nonNegativeInteger"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="unbounded"/> </xs:restriction> </xs:simpleType> </xs:union> </xs:simpleType> <xs:attributeGroup name="occurs"> <xs:annotation> <xs:documentation> for all particles</xs:documentation> </xs:annotation> <xs:attribute name="minOccurs" type="xs:nonNegativeInteger" default="1" use="optional"/> <xs:attribute name="maxOccurs" type="xs:allNNI" default="1" use="optional"/> </xs:attributeGroup> <xs:attributeGroup name="defRef"> <xs:annotation> <xs:documentation> for element, group and attributeGroup, which both define and reference</xs:documentation> </xs:annotation> <xs:attribute name="name" type="xs:NCName"/> <xs:attribute name="ref" type="xs:QName"/> </xs:attributeGroup> <xs:group name="typeDefParticle"> <xs:annotation> <xs:documentation> 'complexType' uses this</xs:documentation> </xs:annotation> <xs:choice> <xs:element name="group" type="xs:groupRef"/> <xs:element ref="xs:all"/> <xs:element ref="xs:choice"/> <xs:element ref="xs:sequence"/> </xs:choice> </xs:group> <xs:group name="nestedParticle"> <xs:choice> <xs:element name="element" type="xs:localElement"/> <xs:element name="group" type="xs:groupRef"/> <xs:element ref="xs:choice"/> <xs:element ref="xs:sequence"/> <xs:element ref="xs:any"/> </xs:choice> </xs:group> <xs:group name="particle"> <xs:choice> <xs:element name="element" type="xs:localElement"/> <xs:element name="group" type="xs:groupRef"/> <xs:element ref="xs:all"/> <xs:element ref="xs:choice"/> <xs:element ref="xs:sequence"/> <xs:element ref="xs:any"/> </xs:choice> </xs:group> <xs:complexType name="attribute"> <xs:complexContent> <xs:extension base="xs:annotated"> <xs:sequence> <xs:element name="simpleType" type="xs:localSimpleType" minOccurs="0"/> </xs:sequence> <xs:attributeGroup ref="xs:defRef"/> <xs:attribute name="type" type="xs:QName"/> <xs:attribute name="use" default="optional" use="optional"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="prohibited"/> <xs:enumeration value="optional"/> <xs:enumeration value="required"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="default" type="xs:string"/> <xs:attribute name="fixed" type="xs:string"/> <xs:attribute name="form" type="xs:formChoice"/> <xs:attribute name="targetNamespace" type="xs:anyURI"/> <xs:attribute name="inheritable" type="xs:boolean"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="topLevelAttribute"> <xs:complexContent> <xs:restriction base="xs:attribute"> <xs:sequence> <xs:element ref="xs:annotation" minOccurs="0"/> <xs:element name="simpleType" type="xs:localSimpleType" minOccurs="0"/> </xs:sequence> <xs:attribute name="ref" use="prohibited"/> <xs:attribute name="form" use="prohibited"/> <xs:attribute name="use" use="prohibited"/> <xs:attribute name="targetNamespace" use="prohibited"/> <xs:attribute name="name" type="xs:NCName" use="required"/> <xs:attribute name="inheritable" type="xs:boolean"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:group name="attrDecls"> <xs:sequence> <xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:element name="attribute" type="xs:attribute"/> <xs:element name="attributeGroup" type="xs:attributeGroupRef"/> </xs:choice> <xs:element ref="xs:anyAttribute" minOccurs="0"/> </xs:sequence> </xs:group> <xs:element name="anyAttribute" id="anyAttribute"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/structures.html#element-anyAttribute"/> </xs:annotation> <xs:complexType> <xs:complexContent> <xs:extension base="xs:wildcard"> <xs:attribute name="notQName" type="xs:qnameListA" use="optional"/> </xs:extension> </xs:complexContent> </xs:complexType> </xs:element> <xs:group name="assertions"> <xs:sequence> <xs:element name="assert" type="xs:assertion" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:group> <xs:complexType name="assertion"> <xs:complexContent> <xs:extension base="xs:annotated"> <xs:attribute name="test" type="xs:string"/> <xs:attribute name="xpathDefaultNamespace" type="xs:xpathDefaultNamespace"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:group name="complexTypeModel"> <xs:choice> <xs:element ref="xs:simpleContent"/> <xs:element ref="xs:complexContent"/> <xs:sequence> <xs:annotation> <xs:documentation> This branch is short for <complexContent> <restriction base="xs:anyType"> ... </restriction> </complexContent></xs:documentation> </xs:annotation> <xs:element ref="xs:openContent" minOccurs="0"/> <xs:group ref="xs:typeDefParticle" minOccurs="0"/> <xs:group ref="xs:attrDecls"/> <xs:group ref="xs:assertions"/> </xs:sequence> </xs:choice> </xs:group> <xs:complexType name="complexType" abstract="true"> <xs:complexContent> <xs:extension base="xs:annotated"> <xs:group ref="xs:complexTypeModel"/> <xs:attribute name="name" type="xs:NCName"> <xs:annotation> <xs:documentation> Will be restricted to required or prohibited</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="mixed" type="xs:boolean" use="optional"> <xs:annotation> <xs:documentation> Not allowed if simpleContent child is chosen. May be overridden by setting on complexContent child.</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="abstract" type="xs:boolean" default="false" use="optional"/> <xs:attribute name="final" type="xs:derivationSet"/> <xs:attribute name="block" type="xs:derivationSet"/> <xs:attribute name="defaultAttributesApply" type="xs:boolean" default="true" use="optional"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="topLevelComplexType"> <xs:complexContent> <xs:restriction base="xs:complexType"> <xs:sequence> <xs:element ref="xs:annotation" minOccurs="0"/> <xs:group ref="xs:complexTypeModel"/> </xs:sequence> <xs:attribute name="name" type="xs:NCName" use="required"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:complexType name="localComplexType"> <xs:complexContent> <xs:restriction base="xs:complexType"> <xs:sequence> <xs:element ref="xs:annotation" minOccurs="0"/> <xs:group ref="xs:complexTypeModel"/> </xs:sequence> <xs:attribute name="name" use="prohibited"/> <xs:attribute name="abstract" use="prohibited"/> <xs:attribute name="final" use="prohibited"/> <xs:attribute name="block" use="prohibited"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:complexType name="restrictionType"> <xs:complexContent> <xs:extension base="xs:annotated"> <xs:sequence> <xs:choice minOccurs="0"> <xs:sequence> <xs:element ref="xs:openContent" minOccurs="0"/> <xs:group ref="xs:typeDefParticle"/> </xs:sequence> <xs:group ref="xs:simpleRestrictionModel"/> </xs:choice> <xs:group ref="xs:attrDecls"/> <xs:group ref="xs:assertions"/> </xs:sequence> <xs:attribute name="base" type="xs:QName" use="required"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="complexRestrictionType"> <xs:complexContent> <xs:restriction base="xs:restrictionType"> <xs:sequence> <xs:element ref="xs:annotation" minOccurs="0"/> <xs:choice minOccurs="0"> <xs:annotation> <xs:documentation>This choice is added simply to make this a valid restriction per the REC</xs:documentation> </xs:annotation> <xs:sequence> <xs:element ref="xs:openContent" minOccurs="0"/> <xs:group ref="xs:typeDefParticle"/> </xs:sequence> </xs:choice> <xs:group ref="xs:attrDecls"/> <xs:group ref="xs:assertions"/> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:complexType name="extensionType"> <xs:complexContent> <xs:extension base="xs:annotated"> <xs:sequence> <xs:element ref="xs:openContent" minOccurs="0"/> <xs:group ref="xs:typeDefParticle" minOccurs="0"/> <xs:group ref="xs:attrDecls"/> <xs:group ref="xs:assertions"/> </xs:sequence> <xs:attribute name="base" type="xs:QName" use="required"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name="complexContent" id="complexContent"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/structures.html#element-complexContent"/> </xs:annotation> <xs:complexType> <xs:complexContent> <xs:extension base="xs:annotated"> <xs:choice> <xs:element name="restriction" type="xs:complexRestrictionType"/> <xs:element name="extension" type="xs:extensionType"/> </xs:choice> <xs:attribute name="mixed" type="xs:boolean"> <xs:annotation> <xs:documentation> Overrides any setting on complexType parent.</xs:documentation> </xs:annotation> </xs:attribute> </xs:extension> </xs:complexContent> </xs:complexType> </xs:element> <xs:element name="openContent" id="openContent"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/structures.html#element-openContent"/> </xs:annotation> <xs:complexType> <xs:complexContent> <xs:extension base="xs:annotated"> <xs:sequence> <xs:element name="any" minOccurs="0" type="xs:wildcard"/> </xs:sequence> <xs:attribute name="mode" default="interleave" use="optional"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="none"/> <xs:enumeration value="interleave"/> <xs:enumeration value="suffix"/> </xs:restriction> </xs:simpleType> </xs:attribute> </xs:extension> </xs:complexContent> </xs:complexType> </xs:element> <xs:element name="defaultOpenContent" id="defaultOpenContent"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/structures.html#element-defaultOpenContent"/> </xs:annotation> <xs:complexType> <xs:complexContent> <xs:extension base="xs:annotated"> <xs:sequence> <xs:element name="any" type="xs:wildcard"/> </xs:sequence> <xs:attribute name="appliesToEmpty" type="xs:boolean" default="false" use="optional"/> <xs:attribute name="mode" default="interleave" use="optional"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="interleave"/> <xs:enumeration value="suffix"/> </xs:restriction> </xs:simpleType> </xs:attribute> </xs:extension> </xs:complexContent> </xs:complexType> </xs:element> <xs:complexType name="simpleRestrictionType"> <xs:complexContent> <xs:restriction base="xs:restrictionType"> <xs:sequence> <xs:element ref="xs:annotation" minOccurs="0"/> <xs:choice minOccurs="0"> <xs:annotation> <xs:documentation>This choice is added simply to make this a valid restriction per the REC</xs:documentation> </xs:annotation> <xs:group ref="xs:simpleRestrictionModel"/> </xs:choice> <xs:group ref="xs:attrDecls"/> <xs:group ref="xs:assertions"/> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:complexType name="simpleExtensionType"> <xs:complexContent> <xs:restriction base="xs:extensionType"> <xs:sequence> <xs:annotation> <xs:documentation> No typeDefParticle group reference</xs:documentation> </xs:annotation> <xs:element ref="xs:annotation" minOccurs="0"/> <xs:group ref="xs:attrDecls"/> <xs:group ref="xs:assertions"/> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:element name="simpleContent" id="simpleContent"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/structures.html#element-simpleContent"/> </xs:annotation> <xs:complexType> <xs:complexContent> <xs:extension base="xs:annotated"> <xs:choice> <xs:element name="restriction" type="xs:simpleRestrictionType"/> <xs:element name="extension" type="xs:simpleExtensionType"/> </xs:choice> </xs:extension> </xs:complexContent> </xs:complexType> </xs:element> <xs:element name="complexType" type="xs:topLevelComplexType" id="complexType"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/structures.html#element-complexType"/> </xs:annotation> </xs:element> <xs:simpleType name="blockSet"> <xs:annotation> <xs:documentation> A utility type, not for public use</xs:documentation> <xs:documentation> #all or (possibly empty) subset of {substitution, extension, restriction}</xs:documentation> </xs:annotation> <xs:union> <xs:simpleType> <xs:restriction base="xs:token"> <xs:enumeration value="#all"/> </xs:restriction> </xs:simpleType> <xs:simpleType> <xs:list> <xs:simpleType> <xs:restriction base="xs:derivationControl"> <xs:enumeration value="extension"/> <xs:enumeration value="restriction"/> <xs:enumeration value="substitution"/> </xs:restriction> </xs:simpleType> </xs:list> </xs:simpleType> </xs:union> </xs:simpleType> <xs:complexType name="element" abstract="true"> <xs:annotation> <xs:documentation> The element element can be used either at the top level to define an element-type binding globally, or within a content model to either reference a globally-defined element or type or declare an element-type binding locally. The ref form is not allowed at the top level.</xs:documentation> </xs:annotation> <xs:complexContent> <xs:extension base="xs:annotated"> <xs:sequence> <xs:choice minOccurs="0"> <xs:element name="simpleType" type="xs:localSimpleType"/> <xs:element name="complexType" type="xs:localComplexType"/> </xs:choice> <xs:element name="alternative" type="xs:altType" minOccurs="0" maxOccurs="unbounded"/> <xs:group ref="xs:identityConstraint" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attributeGroup ref="xs:defRef"/> <xs:attribute name="type" type="xs:QName"/> <xs:attribute name="substitutionGroup"> <xs:simpleType> <xs:list itemType="xs:QName"/> </xs:simpleType> </xs:attribute> <xs:attributeGroup ref="xs:occurs"/> <xs:attribute name="default" type="xs:string"/> <xs:attribute name="fixed" type="xs:string"/> <xs:attribute name="nillable" type="xs:boolean" use="optional"/> <xs:attribute name="abstract" type="xs:boolean" default="false" use="optional"/> <xs:attribute name="final" type="xs:derivationSet"/> <xs:attribute name="block" type="xs:blockSet"/> <xs:attribute name="form" type="xs:formChoice"/> <xs:attribute name="targetNamespace" type="xs:anyURI"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="topLevelElement"> <xs:complexContent> <xs:restriction base="xs:element"> <xs:sequence> <xs:element ref="xs:annotation" minOccurs="0"/> <xs:choice minOccurs="0"> <xs:element name="simpleType" type="xs:localSimpleType"/> <xs:element name="complexType" type="xs:localComplexType"/> </xs:choice> <xs:element name="alternative" type="xs:altType" minOccurs="0" maxOccurs="unbounded"/> <xs:group ref="xs:identityConstraint" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="ref" use="prohibited"/> <xs:attribute name="form" use="prohibited"/> <xs:attribute name="targetNamespace" use="prohibited"/> <xs:attribute name="minOccurs" use="prohibited"/> <xs:attribute name="maxOccurs" use="prohibited"/> <xs:attribute name="name" type="xs:NCName" use="required"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:complexType name="localElement"> <xs:complexContent> <xs:restriction base="xs:element"> <xs:sequence> <xs:element ref="xs:annotation" minOccurs="0"/> <xs:choice minOccurs="0"> <xs:element name="simpleType" type="xs:localSimpleType"/> <xs:element name="complexType" type="xs:localComplexType"/> </xs:choice> <xs:element name="alternative" type="xs:altType" minOccurs="0" maxOccurs="unbounded"/> <xs:group ref="xs:identityConstraint" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="substitutionGroup" use="prohibited"/> <xs:attribute name="final" use="prohibited"/> <xs:attribute name="abstract" use="prohibited"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:element name="element" type="xs:topLevelElement" id="element"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/structures.html#element-element"/> </xs:annotation> </xs:element> <xs:complexType name="altType"> <xs:annotation> <xs:documentation> This type is used for 'alternative' elements. </xs:documentation> </xs:annotation> <xs:complexContent> <xs:extension base="xs:annotated"> <xs:choice minOccurs="0"> <xs:element name="simpleType" type="xs:localSimpleType"/> <xs:element name="complexType" type="xs:localComplexType"/> </xs:choice> <xs:attribute name="test" type="xs:string" use="optional"/> <xs:attribute name="type" type="xs:QName" use="optional"/> <xs:attribute name="xpathDefaultNamespace" type="xs:xpathDefaultNamespace"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="group" abstract="true"> <xs:annotation> <xs:documentation> group type for explicit groups, named top-level groups and group references</xs:documentation> </xs:annotation> <xs:complexContent> <xs:extension base="xs:annotated"> <xs:group ref="xs:particle" minOccurs="0" maxOccurs="unbounded"/> <xs:attributeGroup ref="xs:defRef"/> <xs:attributeGroup ref="xs:occurs"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="realGroup"> <xs:complexContent> <xs:restriction base="xs:group"> <xs:sequence> <xs:element ref="xs:annotation" minOccurs="0"/> <xs:choice minOccurs="0" maxOccurs="1"> <xs:element ref="xs:all"/> <xs:element ref="xs:choice"/> <xs:element ref="xs:sequence"/> </xs:choice> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:complexType name="namedGroup"> <xs:complexContent> <xs:restriction base="xs:realGroup"> <xs:sequence> <xs:element ref="xs:annotation" minOccurs="0"/> <xs:choice minOccurs="1" maxOccurs="1"> <xs:element name="all"> <xs:complexType> <xs:complexContent> <xs:restriction base="xs:all"> <xs:group ref="xs:allModel"/> <xs:attribute name="minOccurs" use="prohibited"/> <xs:attribute name="maxOccurs" use="prohibited"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType> </xs:element> <xs:element name="choice" type="xs:simpleExplicitGroup"/> <xs:element name="sequence" type="xs:simpleExplicitGroup"/> </xs:choice> </xs:sequence> <xs:attribute name="name" type="xs:NCName" use="required"/> <xs:attribute name="ref" use="prohibited"/> <xs:attribute name="minOccurs" use="prohibited"/> <xs:attribute name="maxOccurs" use="prohibited"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:complexType name="groupRef"> <xs:complexContent> <xs:restriction base="xs:realGroup"> <xs:sequence> <xs:element ref="xs:annotation" minOccurs="0"/> </xs:sequence> <xs:attribute name="ref" type="xs:QName" use="required"/> <xs:attribute name="name" use="prohibited"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:complexType name="explicitGroup"> <xs:annotation> <xs:documentation> group type for the three kinds of group</xs:documentation> </xs:annotation> <xs:complexContent> <xs:restriction base="xs:group"> <xs:sequence> <xs:element ref="xs:annotation" minOccurs="0"/> <xs:group ref="xs:nestedParticle" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="name" use="prohibited"/> <xs:attribute name="ref" use="prohibited"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:complexType name="simpleExplicitGroup"> <xs:complexContent> <xs:restriction base="xs:explicitGroup"> <xs:sequence> <xs:element ref="xs:annotation" minOccurs="0"/> <xs:group ref="xs:nestedParticle" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="minOccurs" use="prohibited"/> <xs:attribute name="maxOccurs" use="prohibited"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:group name="allModel"> <xs:sequence> <xs:element ref="xs:annotation" minOccurs="0"/> <xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:annotation> <xs:documentation>This choice with min/max is here to avoid a pblm with the Elt:All/Choice/Seq Particle derivation constraint</xs:documentation> </xs:annotation> <xs:element name="element" type="xs:localElement"/> <xs:element ref="xs:any"/> <xs:element name="group"> To facilitate consistent reporting of schema errors and · · should cos-ct-extends.1.2 should 1.2 Derivation Valid (Extension) (§3.4.6.2) cvc-accept Element Sequence Accepted (Particle) cvc-assertion Assertion Satisfied cvc-assertions-valid Assertions Valid cvc-assess-attr Schema-Validity Assessment (Attribute) cvc-assess-elt Schema-Validity Assessment (Element) cvc-attribute Attribute Locally Valid cvc-au Attribute Locally Valid (Use) cvc-complex-content Element Sequence Locally Valid (Complex Content) cvc-complex-type Element Locally Valid (Complex Type) cvc-datatype-valid Datatype Valid cvc-elt Element Locally Valid (Element) cvc-enumeration-valid enumeration valid cvc-explicitTimezone-valid explicitOffset Valid cvc-facet-valid Facet Valid cvc-fractionDigits-valid fractionDigits Valid cvc-id Validation Root Valid (ID/IDREF) cvc-identity-constraint Identity-constraint Satisfied cvc-length-valid Length Valid cvc-maxExclusive-valid maxExclusive Valid cvc-maxInclusive-valid maxInclusive Valid cvc-maxLength-valid maxLength Valid cvc-minExclusive-valid minExclusive Valid cvc-minInclusive-valid minInclusive Valid cvc-minLength-valid minLength Valid cvc-model-group Element Sequence Valid cvc-particle Element Sequence Locally Valid (Particle) cvc-pattern-valid pattern valid cvc-resolve-instance QName resolution (Instance) cvc-simple-type String Valid cvc-totalDigits-valid totalDigits Valid cvc-type Element Locally Valid (Type) cvc-wildcard Item Valid (Wildcard) cvc-wildcard-name Wildcard allows Expanded Name cvc-wildcard-namespace Wildcard allows Namespace Name cvc-xpath XPath Evaluation ID/IDREF binding information item properties [binding] ID/IDREF Table [id] ID/IDREF Table Identity-constraint Binding information item properties [definition] Identity-constraint Table [node table] Identity-constraint Table attribute information item properties [attribute attribution] Match Information [attribute declaration] Attribute Declaration [match information] Match Information [member type definition] Attribute Validated by Type [member type definition anonymous] Attribute Validated by Type [member type definition name] Attribute Validated by Type [member type definition namespace] Attribute Validated by Type [member type definitions] Attribute Validated by Type [schema actual value] Attribute Validated by Type [schema default] Attribute Declaration [schema error code] Validation Failure (Attribute) [schema normalized value] Attribute Validated by Type [schema specified] Assessment Outcome (Attribute) [type definition] Attribute Validated by Type [type definition anonymous] Attribute Validated by Type [type definition name] Attribute Validated by Type [type definition namespace] Attribute Validated by Type [type definition type] Attribute Validated by Type [validation attempted] Assessment Outcome (Attribute) [validation context] Assessment Outcome (Attribute) [validity] Assessment Outcome (Attribute) element information item properties [ID/IDREF table] ID/IDREF Table [declared type] Element Declaration [descendant validity] Element Validated by Type [element attribution] Match Information [element declaration] Element Declaration [expected element declaration] Element Declaration [failed assertions] Validation Failure (Element) [failed identity constraints] Validation Failure (Element) [identity-constraint table] Identity-constraint Table [inherited attributes] Inherited Attributes [local element validity] Element Declaration [local type validity] Element Validated by Type [match information] Match Information [member type definition] Element Validated by Type [member type definition anonymous] Element Validated by Type [member type definition name] Element Validated by Type [member type definition namespace] Element Validated by Type [member type definitions] Element Validated by Type [nil] Element Declaration [notation] Validated with Notation [notation public] Validated with Notation [notation system] Validated with Notation [schema actual value] Element Validated by Type [schema default] Element Validated by Type [schema error code] Validation Failure (Element) [schema normalized value] Element Validated by Type [schema specified] Element Default Value [subsequence-valid] Validation Failure (Element) [type alternative] Element Validated by Type [type definition] Element Validated by Type [type definition type] Element Validated by Type [type definition anonymous] Element Validated by Type [type definition name] Element Validated by Type [type definition namespace] Element Validated by Type [type fallback] Element Validated by Type [validation attempted] Assessment Outcome (Element) [validation context] Assessment Outcome (Element) [validity] Assessment Outcome (Element) element or attribute information item properties [schema information] Schema Information namespace schema information information item properties [schema components] Schema Information [schema documents] Schema Information [schema namespace] Schema Information schema document information item properties [document] Schema Information [document location] Schema Information src-attribute Attribute Declaration Representation OK src-attribute_group Attribute Group Definition Representation OK src-cip Conditional Inclusion Constraints src-ct Complex Type Definition Representation OK src-element Element Declaration Representation OK src-enumeration-value Enumeration value src-expredef Individual Component Redefinition src-identity-constraint Identity-constraint Definition Representation OK src-import Import Constraints and Semantics src-include Inclusion Constraints and Semantics src-list-itemType-or-simpleType itemType attribute or simpleType child src-override Override Constraints and Semantics src-pattern-value Pattern value src-redefine Redefinition Constraints and Semantics src-resolve QName resolution (Schema Document) src-restriction-base-or-simpleType base attribute or simpleType child src-simple-type Simple Type Definition Representation OK src-ta Type Alternative Representation OK src-union-memberTypes-or-simpleTypes memberTypes attribute or simpleType children src-wildcard Wildcard Representation OK a-props-correct Attribute Declaration Properties Correct ag-props-correct Attribute Group Definition Properties Correct an-props-correct Annotation Correct as-props-correct Assertion Properties Correct au-props-correct Attribute Use Correct c-fields-xpaths Fields Value OK c-props-correct Identity-constraint Definition Properties Correct c-selector-xpath Selector Value OK cos-all-limited All Group Limited cos-applicable-facets Applicable Facets cos-assertions-restriction Valid restriction of assertions cos-aw-intersect Attribute Wildcard Intersection cos-aw-union Attribute Wildcard Union cos-choice-range Effective Total Range (choice) cos-content-act-restrict Content type restricts (Complex Content) cos-ct-derived-ok Type Derivation OK (Complex) cos-ct-extends Derivation Valid (Extension) cos-element-consistent Element Declarations Consistent cos-equiv-derived-ok-rec Substitution Group OK (Transitive) cos-group-emptiable Particle Emptiable cos-nonambig Unique Particle Attribution cos-ns-subset Wildcard Subset cos-particle-extend Particle Valid (Extension) cos-pattern-restriction Valid restriction of pattern cos-seq-range Effective Total Range (all and sequence) cos-st-derived-ok Type Derivation OK (Simple) cos-st-restricts Derivation Valid (Restriction, Simple) cos-valid-default Element Default Valid (Immediate) cos-valid-simple-default Simple Default Valid ct-props-correct Complex Type Definition Properties Correct derivation-ok-restriction Derivation Valid (Restriction, Complex) e-props-correct Element Declaration Properties Correct enumeration-required-notation enumeration facet value required for NOTATION enumeration-valid-restriction enumeration valid restriction fractionDigits-totalDigits fractionDigits less than or equal to totalDigits fractionDigits-valid-restriction fractionDigits valid restriction length-minLength-maxLength length and minLength or maxLength length-valid-restriction length valid restriction maxExclusive-valid-restriction maxExclusive valid restriction maxInclusive-maxExclusive maxInclusive and maxExclusive maxInclusive-valid-restriction maxInclusive valid restriction maxLength-valid-restriction maxLength valid restriction mg-props-correct Model Group Correct mgd-props-correct Model Group Definition Properties Correct minExclusive-less-than-equal-to-maxExclusive minExclusive <= maxExclusive minExclusive-less-than-maxInclusive minExclusive < maxInclusive minExclusive-valid-restriction minExclusive valid restriction minInclusive-less-than-equal-to-maxInclusive minInclusive <= maxInclusive minInclusive-less-than-maxExclusive minInclusive < maxExclusive minInclusive-minExclusive minInclusive and minExclusive minInclusive-valid-restriction minInclusive valid restriction minLength-less-than-equal-to-maxLength minLength <= maxLength minLength-valid-restriction minLength valid restriction n-props-correct Notation Declaration Correct no-xmlns xmlns Not Allowed no-xsi xsi: Not Allowed p-props-correct Particle Correct sch-props-correct Schema Properties Correct st-props-correct Simple Type Definition Properties Correct st-restrict-facets Simple Type Restriction (Facets) ta-props-correct Type Alternative Properties Correct timezone-valid-restriction timezone valid restriction totalDigits-valid-restriction totalDigits valid restriction w-props-correct Wildcard Properties Correct whiteSpace-valid-restriction whiteSpace valid restriction xpath-valid XPath Valid This section defines some terms for use in describing choices made by implementations in areas where the effect of XSD features is explicitly · · Future versions of this specification are expected to use the terminology defined here to specify conformance profiles. Conformance profiles may also be defined by other specifications without requiring any revision to this specification. This specification defines a number of ways in which the information set taken as input is augmented in the course of schema-validity assessment. Conforming processors may may If other subsets of the PSVI prove important in practice it is expected that definitions of those subsets may The definition in this section of a term denoting a particular subset of the PSVI does not constitute a requirement that conforming processors provide access to that subset. [Definition:] root-validity subset · · [validity] [validation attempted] [schema error code] instance-validity subset [Definition:] instance-validity subset · · [validity] [validation attempted] [notation system] [notation public] [schema error code] [validity] [validation attempted] [schema error code] type-aware subset [Definition:] type-aware subset · · · · [element attribution] [element declaration] [nil] [type definition] [member type definition] [schema normalized value] [schema actual value] [attribute attribution] [attribute declaration] [type definition] [member type definition] [schema normalized value] [schema actual value] Note: should must lightweight type-aware subset [Definition:] lightweight type-aware subset · · [match information] [type definition name] [type definition namespace] [type definition type] [type definition anonymous] [member type definition name] [member type definition namespace] [member type definition anonymous] [match information] [type definition name] [type definition namespace] [type definition type] [type definition anonymous] [member type definition name] [member type definition namespace] [member type definition anonymous] full instance subset [Definition:] full instance subset · · [descendant validity] [local element validity] [local type validity] [subsequence-valid] [match information] [type definition name] [type definition namespace] [type definition type] [type definition anonymous] [type fallback] [type alternative] [member type definition name] [member type definition namespace] [member type definition anonymous] [schema normalized value] [schema actual value] [schema default] [schema information] · · [match information] [type definition name] [type definition namespace] [type definition type] [type definition anonymous] [member type definition name] [member type definition namespace] [member type definition anonymous] [schema normalized value] [schema actual value] [schema default] [schema specified] full PSVI with components The full PSVI with components In exposing element declarations, attribute declarations, type definitions, and other components, processors providing access to the full subset must provide some representation for all of the defined properties of the components. Note that although the properties are often redundant with other information, it is not required that the full subset include more than one representation of redundant information. Note: [type definition name] [name] [type definition] [type definition] [type definition name] Similar observations can be made for other properties present in the full-instance subset but not mentioned here. Processors should C.2.1 Identifying locations where components are sought Identifying methods of indirection Identifying the key for use in indirection Identifying when to stop searching Identifying how to react to failure Conforming processors may may The terminology offered here is intended to be useful in discussions of processor behavior, whether documenting existing behavior or describing required behavior. General-purpose processors should Some terms describe how a processor identifies locations from which schema components can be sought: hard-coded schemas Full knowledge of one or more schemas is built into the processor. (Note: all processors are required to have some built-in knowledge of of the built-in components. · · · · · · Full knowledge of one or more components is built into the processor; these components may may · · Note: hard-coded schema locations A list of locations at which schema documents will be sought is built into the processor. Particular locations can be associated with specific namespaces or can be used to seek any schema document. named pairs At invocation time, the user passes a set or sequence of (namespace-name, schema document) pairs to the processor, e.g. as a command-line option. (Can be used with early or slow exit strategy.) The namespace name is used as a check on the document, not as an instruction; if the schema document has a target namespace which differs from the namespace name specified, the processor signals an error. schema documents At invocation time, the user passes a set or sequence of schema documents, or identifiers for schema documents (e.g. URIs), to the processor, e.g. as a command-line option. Each schema document is associated with its target namespace, if any. (Can be used with early or slow exit strategy.) interactive inquiry For each namespace, the processor asks the user interactively (though mechanisms not specified here) where to seek the required schema components. Note: namespace name For each namespace, the processor attempts to dereference the namespace name; if a schema document is returned, it is processed. If some other kind of resource representation is returned, processors may Note: may rddl:resource xlink:role http://www.w3.org/2001/XMLSchema xlink:href schemaLocation hints in XML instance document For each namespace, if the input document includes one or more schemaLocation hints for that namespace, the processor attempts to dereference those locations. schemaLocation hints in schema documents For each namespace, if a schema document being processed includes one or more schemaLocation hints for that namespace (e.g. on an import local repository For each namespace, a local repository of schema components is consulted. In some situations the consultation will require a key, in which see the terminology for indirection given below. Some terms describe various methods of indirection through local catalogs, search paths, or local repositories of schema documents and/or schema components. In each of these, a ‘search key’ is assumed which helps to control the indirection. Terms for different sorts of search key are defined below. path indirection The processor has (hard-coded or accepted as a parameter at invocation time or acquired from the environment) a series of expressions into which a search key is substituted. After substitution, each element of the series is interpreted as a file-system path and a schema document is sought at the location indicated by that path. URI indirection The processor has (hard-coded or accepted as a parameter at invocation time or acquired from the environment) a series of expressions into which a search key is substituted. After substitution, each element of the series is interpreted as a URI and a schema document is sought at the location indicated by that path. catalog indirection The processor consults an OASIS catalog (whose location can be hard-coded, passed as a parameter at invocation time or acquired from the environment) using a search key. The key can be sought for as a namespace name, as a public identifier, or as a system identifier. local repository indirection A local repository of schema components is consulted using a search key. recursion The location(s) returned by a catalog or other indirection mechanism are not consulted immediately but instead used as a key in a renewed indirection. Only after the indirection mechanism fails to return a value is an attempt made to dereference the last location returned. non-recursion The location(s) returned by a catalog or other indirection mechanism are consulted immediately; they are not used in recursive indirections. Locating schema components by means of any of the ‘indirect’ methods just identified will sometimes involve the specification of a value of some kind as a search key. Processors may namespace key The namespace name is used as a key. location key A location (e.g. a schema location hint or the location specified in a catalog or by the user) is used as a key. When more than one location is available for a given namespace, two distinct behaviors can be distinguished; these are orthogonal to other terms defined here: early-exit When more than one location is available for a given namespace, the processor attempts each in turn. When a location is successfully dereferenced and a schema document is obtained, the later locations on the list are ignored. slow-exit When more than one location is available for a given namespace, the processor attempts each in turn. All locations are tried, even if a schema document for the namespace has been obtained. When a processor seeks schema components at a particular location, but fails to find components of the namespace in question at that location, several different ways of responding to that failure can be distinguished: error The processor signals an error in some manner appropriate to its construction and environment. Some processors and some users will find it useful to distinguish fatal errors (which cause processing to halt) from recoverable errors. continue The processor signals no fatal error and continues its search for components in the namespace in question by attempting another location. This section defines terms intended to be useful in describing other implementation-defined choices. The datatypes defined by [XML Schema: Datatypes] [XML 1.0] [Namespaces in XML 1.0] The datatypes defined by [XML Schema: Datatypes] [XML 1.1] [XML Namespaces 1.1] This specification requires as a precondition for · · [XML Infoset] Attribute Information Item [local name] [namespace name] [normalized value] [prefix] [attribute type] [owner element] Character Information Item [character code] [parent] Comment Information Item [content] [parent] Element Information Item [local name] [namespace name] [children] [attributes] [in-scope namespaces] [namespace attributes] [prefix] [base URI] [parent] Namespace Information Item [prefix] [namespace name] Processing Instruction Item [target] [content] [base URI] [parent] In addition, infosets should [unparsed entities] ENTITY ENTITIES · · [unparsed entities] Unparsed Entity Information Item [name] [system identifier] [public identifier] This specification does not require any destructive alterations to the input information set: all the information set contributions specified herein are additive. This appendix is intended to satisfy the requirements for Conformance [XML Infoset] [Definition:] implementation-defined may must · · · · This appendix provides a summary of XSD features whose effect is explicitly · · must In describing the choices made for a given processor, it is hoped that the terminology defined in Terminology for implementation-defined features (normative) (§C) 1 XSD 1.1 depends on other specifications for the definitions of some data types such as string QName NCName Dependencies on Other Specifications (§1.4) · · string [XML 1.1] [XML 1.0] NCName [XML 1.0] [XML 1.1] [Namespaces in XML 1.0] [XML Namespaces 1.1] may · · 2 It is · · Conformance (§2.4) 3 Whether a processor is able to retrieve schema documents from the Web is · · Conformance (§2.4) · · 4 The way in which a processor is invoked, and the way in which values are specified for the schema to be used, the information item to be validated, and the declaration or definition with which to begin validation, is · · Assessing Schema-Validity (§5.2) 5 The manner in which a processor provides access to the information items and properties in the PSVI to any downstream or user applications, or to the invoker, is · · Conformance (§2.4) 6 It is · · Subset of the Post-schema-validation Infoset (§C.1) 7 When the · · [type definition name] · · 8 The method used for assembling a set of schema components for use in validation is · · How schema definitions are located on the Web (§4.3.2) Terminology of schema construction (§C.2) 9 It is · · [type definition name] [member type definition name] Attribute Validated by Type (§3.2.5.4) Element Validated by Type (§3.3.5.4) · · 10 Everything · · [XML Schema: Datatypes] · · Note: · · · · · · · · · · · · · · · · appendix [XML Schema: Datatypes] 11 It is · · 2.4.2 Derivation Valid (Restriction, Complex) (§3.4.6.3) · · T T {base type definition} · · 12 It is · · The values of current dateTime and implicit timezone are also · · XPath Evaluation (§3.13.4.2) The values of various properties in the static context used for XPath evaluation are · · XPath Valid (§3.13.6.2) 13 · · Type Table Type Alternative must Element Declarations Consistent (§3.8.6.3) 14 It is · · <annotation> · · 15 It is · · [XDM] Assertion Satisfied (§3.13.4.1) 16 The function signatures available when XPath expressions in type alternatives are evaluated is · · Constraints on Type Alternative Schema Components (§3.12.6) [Definition:] implementation-dependent may · · · · This appendix provides a summary of XSD features whose effect is explicitly · · not When a default value of type QName NOTATION · · · · {lexical form} {value} When a default value is supplied for a defaulted attribute and more than one prefix is bound to the namespace of the attribute in the [in-scope namespaces] · · When a default value is supplied for a defaulted attribute and · · · · When a default value is supplied for a defaulted attribute and · · · · [Namespaces in XML 1.0] [XML Namespaces 1.1] · · [XML Namespaces 1.1] If more than one Identity-Constraint Definition · · [failed identity constraints] If more than one Assertion · · [failed assertions] The order of Annotation · · If a name is supplied for anonymous components (for example, [type definition name] [member type definition name] · · · · If a processor detects some violations of clause 2.4.2 Derivation Valid (Restriction, Complex) (§3.4.6.3) · · T T {base type definition} · · The transformations specified in the following sections in the form of [XSLT 2.0] [XSLT 2.0] When a <schema> D2 targetNamespace [attribute] Assembling a schema for a single target namespace from multiple schema definition documents ( <include> Including modified component definitions ( <redefine> Overriding component definitions ( <override> <schema> D1 targetNamespace [attribute] [XSLT 2.0] D2 Add a targetNamespace [attribute] D2 targetNamespace [attribute] D1 Update all QName references in D2 · · targetNamespace [attribute] Stylesheet for Chameleon Inclusion <?xml version="1.0" encoding="UTF-8"?> <xsl:transform xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:f="http://www.w3.org/2008/05/XMLSchema-misc" version="2.0"> <xsl:param name="newTargetNamespace" as="xs:anyURI" required="yes"/> <xsl:param name="prefixForTargetNamespace" as="xs:NCName" select="f:generateUniquePrefix(., 0)"/> <xsl:template match="@*|node()"> <xsl:copy><xsl:apply-templates select="@*|node()"/></xsl:copy> </xsl:template> <xsl:template match="xs:schema"> <xsl:copy> <xsl:namespace name="{$prefixForTargetNamespace}" select="$newTargetNamespace"/> <xsl:apply-templates select="@*"/> <xsl:attribute name="targetNamespace" select="$newTargetNamespace"/> <xsl:apply-templates/> </xsl:copy> </xsl:template> <xsl:template match="xs:*/@ref | xs:*/@base | xs:*/@type | xs:schema/@defaultAttributes | xs:keyref/@refer | xs:list/@itemType"> <xsl:choose> <xsl:when test="namespace-uri-from-QName(resolve-QName(string(.), ..))=''"> <xsl:attribute name="{name()}" select="concat($prefixForTargetNamespace, ':', local-name-from-QName(resolve-QName(string(.), ..)))"/> </xsl:when> <xsl:otherwise> <xsl:copy/> </xsl:otherwise> </xsl:choose> </xsl:template> <xsl:template match="@memberTypes | @substitutionGroup"> <xsl:variable name="context" select=".."/> <xsl:variable name="values" as="xs:string+"> <xsl:for-each select="tokenize(., '\s+')"> <xsl:variable name="oldValue" select="resolve-QName(., $context)" as="xs:QName"/> <xsl:sequence select="if (namespace-uri-from-QName($oldValue) eq '') then concat($prefixForTargetNamespace, ':', local-name-from-QName($oldValue)) else string(.)"/> </xsl:for-each> </xsl:variable> <xsl:attribute name="{name()}" select="string-join($values, ' ')"/> </xsl:template> <xsl:template match="@notQName"> <xsl:variable name="context" select=".."/> <xsl:variable name="values" as="xs:string+"> <xsl:for-each select="tokenize(., '\s+')"> <xsl:variable name="oldValue" select="if (starts-with(.,'##')) then () else resolve-QName(., $context)" as="xs:QName?"/> <xsl:sequence select="if (starts-with(.,'##')) then string(.) else if ((namespace-uri-from-QName($oldValue) eq '') or empty(namespace-uri-from-QName($oldValue))) then concat($prefixForTargetNamespace, ':', local-name-from-QName($oldValue)) else string(.)"/> </xsl:for-each> </xsl:variable> <xsl:attribute name="{name()}" select="string-join($values, ' ')"/> </xsl:template> <xsl:function name="f:generateUniquePrefix" as="xs:NCName"> <xsl:param name="xsd"/> <xsl:param name="try" as="xs:integer"/> <xsl:variable name="disallowed" select="distinct-values($xsd//*/in-scope-prefixes(.))"/> <xsl:variable name="candidate" select="xs:NCName(concat('p', $try))"/> <xsl:sequence select="if ($candidate = $disallowed) then f:generateUniquePrefix($xsd, $try+1) else $candidate"/> </xsl:function> </xsl:transform> xs:override When a <schema> D1 <override> [XSLT 2.0] <override> <override> D1 O1 overrideElement <schema> D2 schemaLocation O1 overriddenSchema <schema> D2′ D2 D2 The normative description of the transformation is given by the stylesheet below; the transformation can also be described (non-normatively) in prose as in the following paragraphs. The [attributes] D2′ targetNamespace defaultAttributes [attributes] D2 For each element information item E2 [children] <schema> <redefine> D2 case 1 If E2 <simpleType> <complexType> <group> <attributeGroup> <element> <attribute> <notation> O1 E1 name then D2′ E1 E2 D2 2 If E2 1 O1 then D2′ E2 E2 D2 3 If E2 <include> then D2′ <override> schemaLocation E2 schemaLocation [children] O1 4 If E2 <override> then D2′ <override> E2′ E2′ schemaLocation E2 schemaLocation [children] [children] E2 O1 case 4.1 If E2 O1 1 then E2′ O1 4.2 If E2 O1 1 then 2 E2′ E2 4.3 If O1 E2 1 then E2′ O1 Note: E2′ [children] O1 [children] E2 O1 [children] E2 [children] O1 E2 5 If E2 then D2′ E2 E2 D2 The base URI of D2′ D2 Note: D2′ D2 [children] O1 [children] O1 <include> D2 O1 <override> D2 <override> D2 O1 O1 The result is that the transformation described by O1 · · O1 Note: D2 D2′ D2′ Stylesheet for xs:override <xsl:transform version="2.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:f="http://www.w3.org/2008/05/XMLSchema-misc" exclude-result-prefixes="f"> <xsl:template name="perform-override"> <xsl:param name="overrideElement" as="element(xs:override)"/> <xsl:param name="overriddenSchema" as="element(xs:schema)"/> <xsl:result-document> <xsl:apply-templates select="$overriddenSchema"> <xsl:with-param name="overrideElement" select="$overrideElement"/> </xsl:apply-templates> </xsl:result-document> </xsl:template> <xsl:template match="xs:schema | xs:redefine" priority="5"> <xsl:param name="overrideElement"/> <xsl:copy> <xsl:copy-of select="@*"/> <xsl:apply-templates> <xsl:with-param name="overrideElement" select="$overrideElement"/> </xsl:apply-templates> </xsl:copy> </xsl:template> <xsl:template match="xs:import" priority="5"> <xsl:copy-of select="."/> </xsl:template>
<!--* replace children of xs:schema, xs:redefine, * and xs:override which match children of * $overrideElement. Retain others. *--> <xsl:template match="xs:schema/* | xs:redefine/* | xs:override/*" priority="3"> <xsl:param name="overrideElement"/> <xsl:variable name="original" select="."/> <xsl:variable name="replacement" select="$overrideElement/* [node-name(.) = node-name($original) and f:componentName(.) = f:componentName($original)]"/> <xsl:copy-of select="($replacement, $original)[1]"/> </xsl:template>
<!--* replace xs:include elements with overrides *--> <xsl:template match="xs:include" priority="5"> <xsl:param name="overrideElement"/> <xsl:element name="xs:override"> <xsl:copy-of select="@schemaLocation, $overrideElement/*"/> </xsl:element> </xsl:template> <!--* change xs:override elements: children which match * children of $overrideElement are replaced, others * are kept, and at the end all children of * $overrideElement not already inserted are added. *--> <xsl:template match="xs:override" priority="5"> <xsl:param name="overrideElement"/> <xsl:element name="xs:override"> <xsl:attribute name="schemaLocation"> <xsl:value-of select="@schemaLocation"/> </xsl:attribute> <xsl:apply-templates> <xsl:with-param name="overrideElement" select="$overrideElement"/> </xsl:apply-templates> <xsl:apply-templates select="$overrideElement/*" mode="copy-unmatched"> <xsl:with-param name="overrideElement" select="$overrideElement"/> <xsl:with-param name="overriddenOverride" select="."/> </xsl:apply-templates> </xsl:element> </xsl:template>
<xsl:template match="*" mode="copy-unmatched"> <xsl:param name="overriddenOverride"/> <xsl:variable name="overriding" select="."/> <xsl:variable name="overridden" select="$overriddenOverride/*[ node-name(.) = node-name($overriding) and f:componentName(.) = f:componentName($overriding) ]"/> <xsl:choose> <xsl:when test="count($overridden) > 0"> <!--* do nothing; this element already copied *--> </xsl:when> <xsl:when test="count($overridden) = 0"> <!--* copy this element, it isn't already there *--> <xsl:copy-of select="."/> </xsl:when> </xsl:choose> </xsl:template>
<xsl:function name="f:componentName" as="xs:QName"> <xsl:param name="component" as="element()"/> <xsl:sequence select=" QName($component/ancestor::xs:schema/@targetNamespace, $component/@name)"/> </xsl:function>
</xsl:transform> G.1.1 Relationship between XSD and other specifications XSD versions Changes to content models Assertions and XPath Derivation of complex types Changes to complex type definitions ID, IDREF, and related types Simple type definitions Element declarations Attribute declarations Component structure The process of validation The post-schema-validation infoset Conformance Schema composition Other substantive changes Clarifications and editorial changes Note: Changes to the relationship between this and other specifications: Support for XML 1.1 has been added. It is now implementation defined whether datatypes dependent on definitions in XML ( [XML 1.1] [XML 1.0] [XML Namespaces 1.1] [Namespaces in XML 1.0] To reduce confusion and avert a widespread misunderstanding, the normative references to various W3C specifications now state explicitly that while the reference describes the particular edition of a specification current at the time this specification is published, conforming implementations of this specification are not required to ignore later editions of the other specification but instead may The XPath subset for selectors and fields in section Selector Value OK (§3.11.6.2) Fields Value OK (§3.11.6.3) [XPath 2.0] 8454 Tokens in XPath subset for selectors/fields Schema language versions: A conditional inclusion mechanism is defined, roughly analogous to the XSLT 2.0 use-when #ifdef vc:minVersion vc:maxVersion Identifiers for different versions of XSD are now defined in section Schema Language Identifiers (§1.3.4) Content models: The Unique Particle Attribution (§3.8.6.4) · · · · · · · · · · · · Content models may now use the <openContent> Wildcards may now be defined which allow names in any namespace but those in a set of proscribed namespaces. (In version 1.0 of this specification, only a single namespace, the target namespace of a schema document, could be proscribed.) Also, wildcards can now be written which match any element in a set of namespaces but which exclude a particular set of qualified names from matching the wildcard. Finally, the keyword ##definedSibling Wildcards can now be defined which match any element (in the specified namespaces) which does not Several of the constraints imposed by version 1.0 of this specification on all Wildcards are now allowed in all The value of maxOccurs all all Complex types whose content models are all all The discussion of checking content-type restriction included in an appendix in earlier drafts of this specification has now been removed, as have some references to published algorithms for the problem. Several of the papers referred to are no longer publicly accessible on the Web, and the changes made to the Unique Particle Attribution (§3.8.6.4) 6685 Appendix I Checking content-type restriction References Not Available Group references are now allowed in <xs:all> must minOccurs=maxOccurs=1 must <xs:all> 7031 XSD 1.1 doesn't support conversion of xs:sequence to xs:all because xs:all can't contain groups references Assertions and rules for evaluation of XPaths Support for check clauses to implement some co-occurrence constraints has been added. Each complex type can carry a list of assertions, which are checked when the complex type is used to validate an element information item. The facility for assertions defined in the working draft of 31 August 2006 has been revised. The report <assert> The XPath subset defined for assertions has been eliminated. (A somewhat smaller subset is now defined for conditional type assignment.) Rules are defined for the evaluation of XPath expressions (in assertions, in conditional type assignment, or in identity-constraint definitions). The static and dynamic contexts for XPath evaluation are explicitly specified. Rules are provided for constructing the [XDM] When assertions on a complex type are evaluated, only the subtree rooted in an element of that type is mapped into the data model instance. References to ancestor elements or other nodes outside the subtree are not illegal but will not be effective. For conditional type assignment, neither the ancestors nor the children of the element in question are included; the conditions for type assignment are thus effectively restricted to the attributes of the element. For assertions on simple types, only the value is provided; the dynamic context includes no context item. Rules for assigning types to the nodes of the data model instance are defined. Again, the rules differ for the different uses of XPaths: When assertions are evaluated, all of the elements and attributes descended from the element being validated are typed in the normal way; this has the effect that comparisons among attribute values (for example) are performed in a way consistent with the declarations of the attributes. The element node itself, however, is not typed (since it has not yet been completely validated). For conditional type assignment, the nodes of the data model instance are untyped. The conceptual overview now included in Constraint Components (§2.2.4) 5023 Relationship between identity constraints and assertions The rules for the "available collections" and "default collection" properties of the [XPath 2.0] dynamic context · · 6540 Available documents in assertions The [XPath 2.0] static context explicitly includes [Functions and Operators] fn 6541 Assertions and in-scope functions Derivation of complex types: The rules for checking validity of complex-type restrictions have been simplified by reformulating the constraint in terms of local validity: the set of elements or attributes accepted by a restriction as locally valid must be a subset of those accepted by its base type. The rules for attributes have also been changed. The complex rules involving matching up particles in the base type and particles in the restriction, with their complex case by case analysis, have been replaced by a statement of the constraint which is shorter and more correct. It is now possible to specify a target namespace for local elements and attributes which differs from the target namespace of the schema document itself, when restricting a complex type which has local elements or attributes and which itself is in another namespace. This should simplify the reuse of types from other namespaces. The rules for complex type restriction now allow identity constraints on local elements. To make this possible, identity constraints may now be given names and referred to from elsewhere. Corresponding changes have been made in the description of the Schema · · This draft clarifies the rule requiring that any complex type derived by extension could, in principle, be derived in three steps from · xs:anyType · Complex type definitions (miscellaneous changes): Changes have been made to Locally Declared Type (§3.4.4.1) Element Locally Valid (Complex Type) (§3.4.4.2) Derivation Valid (Restriction, Complex) (§3.4.6.3) Element Declarations Consistent (§3.8.6.3) The elements <complexType> <complexContent> mixed The constraint Element Declarations Consistent (§3.8.6.3) 5940 Element Declarations Consistent The rules for restriction of complex types containing local elements with conditional types have been simplified; this resolves issue 12185 Conditional Type Assignment and substitutability The text has been revised to correct the terminology used to describe correct XPath expressions and to specify that it is · · 11073 Type errors during XPath evaluation The description of assertions has been revised to make it explicit that the data model instance constructed for testing assertions has a parentless element node as its root, and not an element node with a document node as its parent. This change resolves issue 12127 "Root element" in assertion testing ID, IDREF, and related types: Certain constraints involving ID ID ID Constraints on Attribute Declaration Schema Components (§3.2.6) An element may now have multiple attributes of type xs:ID xs:ID xml:ID The validation rules for values of type xs:IDREF xs:ENTITY xs:ENTITIES Elements and attributes of type xs:ID The text has been revised to ensure that the special validation rules for xs:ID xs:IDREF xs:IDREFS xs:ENTITY xs:ENTITIES 10662 Should IDREFS and ENTITIES be magic types? Changes involving simple type definitions and related constraints: A new type definition called anyAtomicType anySimpleType atomic Built-in Simple Type Definitions (§3.16.7) An error in version 1.0 of this specification relating to the construction of union types from other union types has been corrected. Unions may now appear as members of other unions, and all restrictions of unions are correctly enforced; the rule Type Derivation OK (Simple) (§3.16.6.3) · · xsi:type The requirement that a facet value be a "valid restriction" of another, in the context of simple type restriction, has been clarified. No union type may be a member of its own transitive membership, nor may any type derived from the union. (XSD 1.0 forbad union datatypes to be members of other unions and thus had no need to forbid this explicitly.) Since not all datatypes have a defined canonical representation for all of their values, appeals to the canonical forms of values have been eliminated. Changes have been made to ensure that the descriptions of the Simple Type Definition · xs:anySimpleType · [XML Schema: Datatypes] Equality and identity of lists have been clarified. The fact that · xs:anyType · has been clarified 6204 anyType/ur-Type: inconsistent whether it has a base-type Enumerations, value constraints, and identity constraints now accept either or 9196 Enumeration and NaN Changes have been made in section Constraints on XML Representations of Simple Type Definitions (§3.16.3) Constraints on XML Representations of Complex Type Definitions (§3.4.3) 11222 src-simple-type.1 should allow duplicate elements from "##other" namespaces Changes to element declarations: A new form of co-occurrence constraint has now been defined, by allowing the type assigned to element instances to be conditional on properties of the instance (typically attribute values). The addition of conditional type assignment has entailed a number of changes: Introduction of a Type Table Type Alternative Constraints on that table: all types named in the table (including the default) must be · · {type definition} Changes to the XML syntax and XML mapping rules to allow expression of conditional type bindings: the <alternative> <element> Validation rules for conditional types: the definition of · · Rules for evaluating the conditional typing tests (more specifically, rules for constructing a temporary infoset and then building the XDM instance and evaluating the XPath expressions as defined elsewhere; priority of tests is given by document order / component order). PSVI changes to reflect details of the conditional typing: a {type alternative} property is added, and the discussion of [type fallback] now refers to the · · {type definition} · · Introduction of some terminology for discussing conditional types (define · · · · · · Rules for checking type restriction in the presence of conditional types. Introduction of a special · xs:error · Miscellaneous supporting editorial changes. Element declarations may now specify multiple substitution-group heads. Abstract elements may now appear in substitution groups. The treatment of type tables in Element Declarations Consistent (§3.8.6.3) 11076 Element Declarations Consistent: comparing type tables Attributes: Attribute declarations can now be marked {inheritable} Inherited Attributes (§3.3.5.6) Type Alternatives (§3.12) Among other consequences, this allows conditional type assignment to be sensitive to the inherited value of the xml:lang 5003 Applicability of <alternative> element to xml:lang W3C Internationalization Core Working Group The rules for default attribute values now refer to the · · [Value Constraint] The text now makes clear that it is pointless (although not illegal) for schema documents to supply default or fixed values for xsi:type http://www.w3.org/2001/XMLSchema-instance Default attribute groups are now supported. The <schema> defaultAttributes Attribute Group Definition defaultAttributesApply <complexType> xml:id xml:lang All wildcard unions are now expressible; this change resolves issue 6163 3.10.6.3 Attribute Wildcard Union As described in XML Mapping Rule for Named Attribute Groups (§3.6.2.1) <attributeGroup> <attributeGroup> Changes in the structure of schema components: Every component now has an {annotations} property whose value is a sequence of annotation elements and out-of-band attributes. See e.g. The Complex Type Definition Schema Component (§3.4.1) Annotations are no longer allowed to vary in the part of a content model shared by a complex type and its extensions. (This was never possible in components specified using schema documents, but was possible in "born-binary" components.) A {context} The Complex Type Definition Schema Component (§3.4.1) The Schema {identity-constraint definitions} The Schema Itself (§3.17.1) XML Representations of Schemas (§3.17.2) The underlying basis for the definition of all the different kinds of components has changed to make use of a regular and formal tabulation of their properties. This has been achieved by introducing property records global Scope The Element Declaration Schema Component (§3.3.1) The process of validation: When an xsi:type · · · · · · {type definition} · xs:anyType · Element information items which match no particle in a content model are now to be validated using their · · · · · · · · [children] [attributes] [children] [attributes] xsi:type · · xsi:type The terminology of assessment has been changed to avoid the suggestion that an element information item can be · · · · An anomaly in the definition of · · · · 7913 Strange result from definition of governing element declaration The usage of the terms " · · · · Schema-validity and documents (§2.5) 5164 validation vs assessment 6015 [schema11] valid (and its derivations) vs assessment as used in text The definition of Element Locally Valid (Type) (§3.3.4.4) · · 11764 Unresolved xsi:type should not affect validity against a type · · Changes in the description of the · · The presentation of the · · · · · · · · Terms have been defined to describe different subsets of the · · Provision is made for exposing the · · · · {schema actual value} The [element declaration] · · · · · · · · When the · · · · · · When default values are supplied for attributes with qualified names, · · [in-scope namespaces] · · · · · · QName NOTATION · · Annotations given in the XML form of identity-constraint declarations with ref · · 6144 annotation on IDC with a 'ref' attribute is lost Changes to the description of conformance: The set of conformance classes has been revised and clarified. Instead of "minimally conforming", "schema-document aware", and "Web-aware" processors, this specification now defines (in section Conformance (§2.4) · · · · · · · · 7695 Conformance A checklist has been included listing ways in which conforming processors may vary from each other, and terminology has been provided for some of the more important properties of conforming processors, in an attempt to make it easier for implementors to describe concisely which options their processors exercise, and easier for users to describe what kinds of processor they require. The definition of must · · must Implementations are now allowed to support primitive datatypes and facets beyond those defined in [XML Schema: Datatypes] The validity requirements for schema documents are stated more fully and correctly. Schema assembly and composition: The <redefine> · · An <override> <redefine> The discussion of <include> <override> <include> <override> When an xsi:schemaLocation xsi:schemaLocation xsi:schemaLocation No <import> http://www.w3.org/2001/XMLSchema http://www.w3.org/2001/XMLSchema-instance <import> The handling of "chameleon" inclusion and redefinition in schema documents has been simplified. The new target namespace affects any component or property which would have the target namespace if the schema document specified one. This change makes it easier to write assertions in schema documents without a namespace which are intended to be included by schema documents with varying target namespaces. Section Identifying how to react to failure (§C.2.5) error continue Schema processors are now explicitly recommended to provide a user option to control whether the processor attempts to dereference schema locations indicated in schemaLocation 5476 xsi:schemaLocation should be a hint, should be MAY not SHOULD The discussion of schemaLocation How schema definitions are located on the Web (§4.3.2) 6655 The discussion of schema import in Licensing References to Components Across Namespaces (§4.2.6.1) 5779 QName resolution and xs:import Some errors in the XSLT stylesheet of appendix Transformation for Chameleon Inclusion (§F.1) 8573 F.1 Stylesheet for chameleons invalid 8574 F.1 Stylesheet for chameleons incomplete The sections on the XML representation of components have been revised to say explicitly that the constraints and mapping rules defined there apply after, not before, pre-processing. This change resolves issues 11179 minor editorial improvement : parent schema components of a named model group 11354 Mentions of "override" outside of the override section Miscellaneous substantive changes: The discussion of schema-validity assessment and the invocation of conforming processors has been revised; additional invocation patterns have been identified, and names have been given to the different methods of invoking a processor. When an element cannot be strictly validated because no element declaration or type definition is available for it, fallback to lax validation (validating the element against the built-in type · xs:anyType · The XML Representation Constraints no longer refer to the component level; this makes it possible to test a schema document in isolation to determine whether it conforms or fails to conform to these rules. The constraints on the XML representation of schemas have been reformulated to allow them to be checked on schema documents in isolation, rather than requiring knowledge of the rest of the schema into which they will be embedded. The consequence is that some errors are caught not in the XML representation constraints but by having the XML mapping rules generate faulty components so that the error can be detected at the component level. These changes resolve issue 6235 Restriction from xs:anySimpleType The <schema> 5930 defaultOpenContent in the S4SD The setting blockDefault="#all" 6120 Reconsider blockDefault=#all Namespace fixup is now explicitly required in some places where it is needed but was not mentioned before; these changes resolve issue 6445 Namespace fixup and default namespace 6465 Namespace fixup and inherited attributes In the DTD for schema documents ( DTD for Schemas (non-normative) (§I) inheritable xs:attribute 11070 DTD for schema documents: inheritable declared as %URIref In the schema for schema documents, an error in the declaration of xs:group xs:allModel xs:all 11092 Error in S4SD: complexType name="all" is not a valid restriction Clarifications and other editorial changes: Each named constraint is now given in a separate section, to simplify reference to them. The XML mapping rules have been reorganized to make them more perspicuous. The keywords defined by [IETF RFC 2119] must Documentation Conventions and Terminology (§1.5) A note has been added, warning that the replace collapse Several minor corrections and clarifications have been made. The usage of some technical terminology has been clarified, normalized, and aligned where appropriate with the usage in [XML Schema: Datatypes] The title of the specification has been changed, and the language defined here is referred to as XSD, not using the name "XML Schema". This may help reduce confusion between the language defined here and the broader class of XML schema languages in general. Conformance-related language has been reviewed to avoid confusion between the conformance-related usage of the verbs may must should Various new terms have been defined, and some existing terms have been redefined, to reduce confusion and improve legibility. In some cases, existing terms which were felt insufficiently informative have been replaced by new terms which may be more useful. Following the example of XQuery 1.0 and XSLT 2.0, the terms " · · · · · · · · The term "context-determined-declaration" has been replaced with the term · · 4690 Editorial: 'context-determined declarations' needs more work The namespace prefixes used to refer to well known namespaces have been changed and are now more consistent; this resolves issue 4316 Make sure namespace prefixes are used appropriately throughout structures Numerous small changes were made in the interests of clarity, completeness, consistency, and precision, and to correct typographical errors. These changes resolve a number of issues, including: 5140 small editorial changes section 3.3 5148 inconsistent target ns description 5639 when is value V a valid restriction of value Y? 5800 Possibly revise list of required infoset properties 5916 Obsolete editorial note 5917 Typo in 3.1.1 5934 Typo concerning <simpleContent mixed="true"> 6011 [schema11] base URI comments 6156 Typo in 3.4.2 6162 <anyAttribute> allows ##definedSibling 6165 Constraints on XML representation of anyAttribute 6166 Schema Component Model for Wildcards 6167 Attribute Wildcard Intersection 6170 Wildcards and defaultAttributes 6175 Wildcard overlap 6227 Type Derivation OK (simple) 6233 Wrong pointer for [nil] PSVI property Discussions of global components now take <redefine> into account 5918 Top level declarations The usage of " · · · · The text concerning xsi:type Element Locally Valid (Element) (§3.3.4.3) xsi:type 11219 Editorial revision of Element Locally Valid (Element) The text has been revised to make clearer that declarations enclosed in an xs:override elementFormDefault xs:override 10652 xs:override and document-level defaults The constraints forbidding the use of special types as members of unions and item types for lists have been reformulated as part of the definition of the simple type definition component. This resolves issue 11103 Note in section 2.4.1 (Special datatypes as members of a union) The treatment of elements in the Schema namespace occurring within <annotation> Such elements do not participate in the mapping from XML representations to components as defined in this specification ( The Mapping between XML Representations and Components (§3.1.3) The Annotation Schema Component (§3.15.1) Such elements are not required to be valid or to satisfy the XML Representation rules as a condition of conformance for a schema document ( Conformance (§2.4) The Annotation Schema Component (§3.15.1) If such elements are invalid, the effect on schema component construction is · · The Annotation Schema Component (§3.15.1) Checklist of implementation-defined features (§E.1) 10125 Validation of the content of xs:annotation A note has been added to the discussion of <override> 12184 Circularity in xs:override It may be useful to mention some points where possible changes to the specification have been discussed, but on which no changes have, in the end, been made. In some cases, this resulted from the XML Schema Working Group's determination that no change was desirable; in other cases, there was no consensus on the desirability of change, or no consensus on what change should be made. As noted above, some restrictions on all all The namespace-related properties of the basic infoset are · · Other kinds of infoset fixup, however, are still not performed. Attributes of type ID IDREF IDREFS NOTATION Some existing implementations (and specifications) assume that elements of type xs:ID xs:ID The identity of components is still underspecified (although a number of points have been clarified, e.g. by the specification of the {scope} property), with the result that some schemas can be interpreted either as conformant or as non-conformant, depending on the interpretation of the specification's appeals to component identity. The constraint Element Declarations Consistent (§3.8.6.3) The account of schema composition given here has not eliminated all the uncertainties present in XSD 1.0; edge cases remain which different conformant implementations will treat differently. A systematic tabulation of error conditions and definition of a new system of error codes was originally foreseen for XSD 1.1, but has not been completed for inclusion here. No further work in this area is currently anticipated. The listing below is for the benefit of readers of a printed version of this document: it collects together all the definitions which appear in the document above. L(D) For any Element Declaration D L D · · D · · D L(W) For any Wildcard W L W · · W · · W NCName An NCName [XML Namespaces 1.1] NCName [XML Schema: Datatypes] QName A QName [XML Namespaces 1.1] QName [XML Schema: Datatypes] Schema Component Constraint Constraints on the schema components themselves, i.e. conditions components must Schema Component Details (§3) Schema Component Constraints (§B.4) Schema Information Set Contribution Augmentations to · · · · Schema Component Details (§3) Contributions to the post-schema-validation infoset (§B.2) Schema Representation Constraint Constraints on the representation of schema components in XML beyond those which are expressed in Schema for Schema Documents (Structures) (normative) (§A) Schema Component Details (§3) Schema Representation Constraints (§B.3) Type Definition Hierarchy Except for · xs:anyType · · · · · · · · xs:anyType · · · · xs:anyType · Type Definition Hierarchy · xs:anyType · Validation Rules Contributions to · · Schema Component Details (§3) Validation Rules (§B.1) Web-aware Web-aware · · must Representation of Schemas on the World Wide Web (§2.8) How schema definitions are located on the Web (§4.3.2) XSD schema An XSD schema · · absent Throughout this specification, the term absent accept A model group G accept recognize L G accept A particle P accept recognize L P T accepts recognizes L T actual value With reference to any string, interpreted as denoting an instance of a given datatype, the term actual value lexical mapping ancestor The ancestors · · {base type definition} · · {base type definition} annotation mapping The annotation mapping ES AS 1 For every <annotation> [children] ES Annotation AS Note: {attributes} Annotation <annotation> [namespace name] 2 E ES A all 2.1 A E [attributes] 2.2 A [namespace name] 2.3 A [attributes] 1 E Annotation C AS C {application information} C {user information} C {attributes} A E [attributes] 3 AS Annotation annotation mapping The annotation mapping · · anyAtomicType There is a further special datatype called anyAtomicType · · · xs:anySimpleType · · · anySimpleType A special · · · xs:anyType · anySimpleType · · · xs:anySimpleType · atomic values atomic values assessment the word assessment · · assessor A schema-validity assessor assessor · · · · · · · · · · attributed to During · · · · [children] [attributes] attributed to automatically known A type about which a processor possesses prior knowledge, and which the processor can support without any declaration of the type being supplied by the user, is said to be automatically known base particle Let the base particle {content type} {base type definition} base information set properties By base information set properties Required Information Set Items and Properties (normative) (§D) base type definition The type definition used as the basis for an · · · · base type definition basic particle A basic particle Particle {term} · · basic term A basic term Element Declaration Wildcard compete Two Particles P 1 P 2 Particle P compete S · · P P 1 P 2 competing paths Two (or more) · · S Particle P competing paths complete path For a model group M S L M S M complete path incomplete paths component name Declarations and definitions may must name [XML Namespaces 1.1] conditionally selects Given a Type Table T E T conditionally selects S E {test} T {alternatives} Type Alternative · · E Type Alternative · · Type Alternative S conditionally selected E T case 1 If at least one Type Alternative T {alternatives} · · E S Type Alternative 2 If no Type Alternative T {alternatives} · · S T {default type definition} {type definition} constructed Datatypes can be constructed restricting {base type definition} Constraining Facet list {item type definition} union {member type definitions} contains A model group contains · · · · contains A particle contains · · · · content model A particle can be used in a complex type definition to constrain the · · [children] content model context-determined declaration During · · [children] [attributes] · · · · {term} · · Attribute Use {attribute declaration} Attribute Use context-determined declarations declaration declaration · · declared entity name A string is a declared entity name [name] [unparsedEntities] · · default binding When a sequence of element information items ES · · Content Type CT AS 2 3 Element Locally Valid (Complex Type) (§3.4.4.2) Complex Type Definition E ES AS default binding Element Declaration Attribute Use strict lax skip 1 When the item has a · · Element Declaration 2 When the item has a · · · · Attribute Use Attribute Use 3 When the item has a · · · · Attribute Use {attribute declaration} · · {value constraint} · · {inheritable} · · {inheritable} Attribute Use 4 When the item is · · strict · · Open Content strict Wildcard · · · · strict 5 When the item is · · lax · · Open Content lax Wildcard · · · · lax 6 When the item is · · skip · · Open Content skip Wildcard skip defaulted attribute A defaulted attribute E · · T Attribute Use U all 1 U T {attribute uses} 2 U {required} false 3 U · · · · 4 U {attribute declaration} Attribute Declaration Built-in Attribute Declarations (§3.2.7) 5 U {attribute declaration} E [attributes] 2.1 Element Locally Valid (Complex Type) (§3.4.4.2) definition definition definition of anyType A special complex type definition, (referred to in earlier versions of this specification as 'the ur-type definition') whose name is anyType · · definition of anyType derived If a type definition D B D derived B directly contains A model group directly contains {particles} directly contains A particle directly contains {term} effective value constraint The effective value constraint U U {value constraint} U {attribute declaration} {value constraint} effective value constraint · · element particle An element particle Particle {term} Element Declaration element substitution group Through the mechanism of element substitution groups equivalent type alternative Any Type Alternative equivalent Type Alternative T1 equivalent Type Alternative T2 T1 {test} T2 {test} T1 {type definition} T2 {type definition} · · must T1 T2 all 1 T1 {test} {namespace bindings} T2 {test} {namespace bindings} Namespace Binding T1 {test} {namespace bindings} T2 {test} {namespace bindings} {prefix} {namespace} 2 T1 {test} {default namespace} T2 {test} {default namespace} · · 3 T1 {test} {base URI} T2 {test} {base URI} · · 4 T1 {test} {expression} T2 {test} {expression} 5 T1 {type definition} T2 {type definition} may equivalent type table A Type Table T1 equivalent Type Table T2 all 1 T1 {alternatives} T2 {alternatives} · · 2 T1 {default type definition} T2 {default type definition} · · extension A complex type definition which allows element or attribute content in addition to that allowed by another specified type definition is said to be an extension field subset of XPath The subset of XPath defined in Fields Value OK (§3.11.6.3) field subset final the complex type is said to be final · · full instance subset The full instance subset · · general-purpose A general-purpose · · · · Layer 2: Schema Documents, Namespaces and Composition (§4.2) governing The declaration associated with an information item, if any, and with respect to which its validity is · · govern governing governing governing attribute declaration In a given schema-validity · · · · governing attribute declaration 1 A declaration which was stipulated by the processor (see Assessing Schema-Validity (§5.2) 2 Its · · 3 A declaration · · [local name] [namespace name] · · · · · · · · · · governing element declaration The governing element declaration E · · 1 A declaration stipulated by the processor (see Assessing Schema-Validity (§5.2) 2 E · · 3 A declaration · · E [local name] [namespace name] E · · strict · · lax · · 4 · · E [local name] [namespace name] none 4.1 E · · 4.2 the processor has stipulated a type definition for E 4.3 a · · · · E E · · E · · · · governing type definition The governing type definition E · · 1 An · · · · Assessing Schema-Validity (§5.2) 2 A type definition stipulated by the processor (see Assessing Schema-Validity (§5.2) 3 An · · · · · · E 4 The · · E 5 The value · · E · · 6 An · · · · · · 7 The · · 8 An · · · · · · governing type definition The governing type definition · · 1 A type definition stipulated by the processor (see Assessing Schema-Validity (§5.2) 2 The {type definition} · · · · · · grouping A grouping implementation-defined An implementation-defined may must implementation-dependent An implementation-dependent may implicitly contains A list of particles implicitly contains · · indirectly contains A model group indirectly contains · · · · indirectly contains A particle indirectly contains {term} initial value the initial value [normalized value] initial value [character code] [children] instance-specified type definition An instance-specified type definition 1 Among the element's attribute information items is one named xsi:type 2 The · · · · QName String Valid (§3.16.4) 3 The · · · · · · instance-specified type definition instance-validity subset The instance-validity subset · · item isomorphic to a component by an item isomorphic laxly assessed The schema validity of an element information item E laxly assessed both 1 E · · · · 2 E · · · xs:anyType · Element Locally Valid (Type) (§3.3.4.4) E [attributes] [children] 2 3 Schema-Validity Assessment (Element) (§3.3.4.6) locally declared type Every Complex Type Definition expanded names locally declared type Complex Type Definition locally declared type For a given Complex Type Definition CTD A · · A CTD case 1 If CTD · xs:anyType · then · · 2 If A expanded name D {attribute declaration} Attribute Use CTD {attribute uses} then {type definition} D 3 otherwise · · A CTD {base type definition} locally declared type For a given Complex Type Definition CTD E · · E CTD case 1 If CTD · xs:anyType · then · · 2 If E expanded name D · · CTD · · · · · · then {type definition} D 3 otherwise · · E CTD {base type definition} locally valid A sequence of element information items is locally valid Content Type Element Sequence Locally Valid (Complex Content) (§3.4.4.3) Content Type locally valid A sequence S locally valid P S · · P V P match An element information item E matches Element Declaration D one 1 E D expanded name 2 The expanded name E · · D 2 · · D match An expanded name E matches · · N NS N NS match E The local name of E N Either the namespace name of E NS E E NS · · match An element information item E matches Wildcard W · · {term} W E · · W Item Valid (Wildcard) (§3.10.4.1) match Two namespace names N 1 N 2 match · · namespace fixup When default values are supplied for attributes, namespace fixup · · E N 1 If the [in-scope namespaces] E N E 2 Otherwise, first select some prefix P [in-scope namespaces] E · · 3 Add an entry to the [in-scope namespaces] E P N 4 Add a namespace attribute to the [namespace attributes] E 5 Maintain the consistency of the information set by adjusting the namespace bindings on the descendants of E 5.1 Add the binding of P N [in-scope namespaces] E P 5.2 Add to the [namespace attributes] E P P · · P [XML Namespaces 1.1] [Namespaces in XML 1.0] The choice between the two methods of maintaining consistency in the information set is · · nilled An element information item E nilled D all 1 E xsi:nil true 2 D {nillable} true normalized value The normalized value · · whiteSpace facet pre-lexical facets · · preserve No normalization is done, the whitespace-normalized value is the · · replace All occurrences of #x9 #xA #xD #x20 collapse Subsequent to the replacements specified above under replace #x20 #x20 #x20 normalized value whiteSpace facet pre-lexical facets overlay Given two sets of facets B S overlaying B S R all 1 Every facet in S R 2 Every facet in B R S R 3 Every facet in R 1 2 override An · · S override T 1 S · · E · · E 2 S · · T {disallowed substitutions} E · · · · T · · Note: T · · E T Assessing Schema-Validity (§5.2) E · · T T · · E partition A partition may path When a sequence S M · · S path S M S M S M Language Recognition by Groups (§3.8.4.1) Principles of Validation against Particles (§3.9.4.1) post-schema-validation infoset We refer to the augmented infoset which results from conformant processing as defined in this specification as the post-schema-validation infoset PSVI potentially inherited An attribute information item A Attribute Default Value (§3.4.5.1) potentially inherited E all 1 A [attributes] E 2 A E [validation context] 3 One 3.1 A · · Attribute Use {inheritable} true 3.2 A not · · Attribute Use A · · {inheritable} true present A property value which is not · · present property record a property value may itself be a collection of named values, which we call a property record resolve A · · resolves to QName resolution (Schema Document) (§3.17.6.2) · · resolves to QName resolution (Instance) (§3.17.6.3) restriction A type defined with the same constraints as its · · restriction root-validity subset The root-validity subset · · schema component Schema component schema document A document in this form (i.e. a <schema> schema document schema-validity assessment As it is used in this specification, the term schema-validity assessment 1 Determining local schema-validity, that is whether an element or attribute information item satisfies the constraints embodied in the relevant components of an XSD schema (specifically the · · · · 2 Determining an overall validation outcome for the item by combining local schema-validity with the results of schema-validity assessments of its descendants, if any; and 3 Determining the appropriate augmentations to the infoset (and, if desired, exposing them to downstream applications in some way, to record this outcome). selected type definition The selected type definition S E E D · · E 1 If D {type table} S · · E D {type table} 2 If D {type table} S D {type definition} E · · E selector subset of XPath The subset of XPath defined in Selector Value OK (§3.11.6.2) selector subset skipped An element or attribute information item is skipped · · skip special-purpose A schema processor which is not a · · special-purpose strictly assessed An element information item E strictly assessed all 1 One 1.1 All 1.1.1 A · · E · · 1.1.2 E · · Element Locally Valid (Element) (§3.3.4.3) 1.1.3 If that evaluation involved the evaluation of Element Locally Valid (Type) (§3.3.4.4) 1 1.2 All 1.2.1 E · · 1.2.2 A · · E · · 1.2.3 The local · · E · · Element Locally Valid (Type) (§3.3.4.4) 2 E [attributes] case 2.1 If · · then Schema-Validity Assessment (Attribute) (§3.2.4.3) 2.2 otherwise 3 [children] case 3.1 If · · · · then Schema-Validity Assessment (Element) (§3.3.4.6) 3.2 If · · skip Wildcard then 3.3 otherwise · · · xs:anyType · substitutable One element declaration is substitutable Substitution Group OK (Transitive) (§3.3.6.3) substitution group Every element declaration (call this HEAD {element declarations} substitution group {element declarations} substitution group HEAD · · HEAD successfully selects A Type Alternative A successfully selects Type Definition T E A {test} true A {type definition} T symbol space this specification introduces the term symbol space target namespace Several kinds of component have a target namespace · · [XML Namespaces 1.1] target set The target set <override> E all 1 The schema document identified by the schemaLocation E 2 The schema document identified by the schemaLocation <override> · · E 3 The schema document identified by the schemaLocation <include> · · E target set E type definition This specification uses the phrase type definition type-aware subset The type-aware subset · · type-aware subset The lightweight type-aware subset · · typed value When the · · · · · · T T user option A choice left under the control of the user of a processor, rather than being fixed for all users or uses of the processor. Statements in this specification that "Processors may may must not must Note: Note: valid Validation [validity] valid extension A complex type T valid extension {base type definition} T {derivation method} extension T Derivation Valid (Extension) (§3.4.6.2) valid restriction A complex type definition with {derivation method} restriction valid restriction {base type definition} Derivation Valid (Restriction, Complex) (§3.4.6.3) valid restriction A simple type definition T valid restriction {base type definition} T Derivation Valid (Restriction, Simple) (§3.16.6.2) validating type When a string N T Datatype Valid · · V 1 The validating type V T T basic member T transitive membership · · N 2 If the · · V L {item type definition} L I validating type A V I I basic member I transitive membership · · N A validation root The element or attribute information item at which · · validation root validation-path For any sequence S P · · S P validation-path · · · · S · · · · validator A validator instance validator · · · · · · · · Schema-validity and documents (§2.5) may · · validly substitutable A type definition S validly substitutable T K substitution extension restriction list union {disallowed substitutions} {prohibited substitutions} S T S T K T {prohibited substitutions} Type Derivation OK (Complex) (§3.4.6.5) S T S · · T K Type Derivation OK (Complex) (§3.4.6.5) S S · · T K Type Derivation OK (Simple) (§3.16.6.3) validly substitutable without limitation If the set of keywords controlling whether a type S · · T S validly substitutable T without limitation absolutely validly substitutable validly substitutable as a restriction A type definition S validly substitutable as a restriction T S · · T extension list union wildcard particle A wildcard particle Particle {term} Wildcard {process contents} {term} xs:error A special simple type definition, whose name is error · · XSD error The DTD for schema documents is given below. Note there is no schema must Independent copies of this material are available in an undated (mutable) version at http://www.w3.org/2009/XMLSchema/XMLSchema.dtd http://www.w3.org/2012/04/XMLSchema.dtd Although this DTD is non-normative, any XML document which is not valid per this DTD, given redefinitions in its internal subset of the 'p' and 's' parameter entities below appropriate to its namespace declaration of the XSD namespace, is almost certainly not a valid schema document, with the exception of documents with multiple namespace prefixes for the XSD namespace itself. Accordingly authoring · · · · DTD for Schema Documents <!-- DTD for XML Schema Definition Language Part 1: Structures Public Identifier: "-//W3C//DTD XSD 1.1//EN" Official Location: http://www.w3.org/2009/XMLSchema/XMLSchema.dtd --> <!-- Id: structures.dtd,v 1.1 2003/08/28 13:30:52 ht Exp --> <!-- With the exception of cases with multiple namespace prefixes for the XSD namespace, any XML document which is not valid per this DTD given redefinitions in its internal subset of the 'p' and 's' parameter entities below appropriate to its namespace declaration of the XSD namespace is almost certainly not a valid schema document. -->
<!-- See below (at the bottom of this document) for information about the revision and namespace-versioning policy governing this DTD. --> <!-- The simpleType element and its constituent parts are defined in XML Schema Definition Language Part 2: Datatypes --> <!ENTITY % xs-datatypes PUBLIC '-//W3C//DTD XSD 1.1 Datatypes//EN' 'datatypes.dtd' >
<!ENTITY % p 'xs:'> <!-- can be overridden in the internal subset of a schema document to establish a different namespace prefix --> <!ENTITY % s ':xs'> <!-- if %p is defined (e.g. as foo:) then you must also define %s as the suffix for the appropriate namespace declaration (e.g. :foo) --> <!ENTITY % nds 'xmlns%s;'>
<!-- Define all the element names, with optional prefix --> <!ENTITY % schema "%p;schema"> <!ENTITY % defaultOpenContent "%p;defaultOpenContent"> <!ENTITY % complexType "%p;complexType"> <!ENTITY % complexContent "%p;complexContent"> <!ENTITY % openContent "%p;openContent"> <!ENTITY % simpleContent "%p;simpleContent"> <!ENTITY % extension "%p;extension"> <!ENTITY % element "%p;element"> <!ENTITY % alternative "%p;alternative"> <!ENTITY % unique "%p;unique"> <!ENTITY % key "%p;key"> <!ENTITY % keyref "%p;keyref"> <!ENTITY % selector "%p;selector"> <!ENTITY % field "%p;field"> <!ENTITY % group "%p;group"> <!ENTITY % all "%p;all"> <!ENTITY % choice "%p;choice"> <!ENTITY % sequence "%p;sequence"> <!ENTITY % any "%p;any"> <!ENTITY % anyAttribute "%p;anyAttribute"> <!ENTITY % attribute "%p;attribute"> <!ENTITY % attributeGroup "%p;attributeGroup"> <!ENTITY % include "%p;include"> <!ENTITY % import "%p;import"> <!ENTITY % redefine "%p;redefine"> <!ENTITY % override "%p;override"> <!ENTITY % notation "%p;notation"> <!ENTITY % assert "%p;assert">
<!-- annotation elements --> <!ENTITY % annotation "%p;annotation"> <!ENTITY % appinfo "%p;appinfo"> <!ENTITY % documentation "%p;documentation">
<!-- Customisation entities for the ATTLIST of each element type. Define one of these if your schema takes advantage of the anyAttribute='##other' in the schema for schema documents -->
<!ENTITY % schemaAttrs ''> <!ENTITY % defaultOpenContentAttrs ''> <!ENTITY % complexTypeAttrs ''> <!ENTITY % complexContentAttrs ''> <!ENTITY % openContentAttrs ''> <!ENTITY % simpleContentAttrs ''> <!ENTITY % extensionAttrs ''> <!ENTITY % elementAttrs ''> <!ENTITY % groupAttrs ''> <!ENTITY % allAttrs ''> <!ENTITY % choiceAttrs ''> <!ENTITY % sequenceAttrs ''> <!ENTITY % anyAttrs ''> <!ENTITY % anyAttributeAttrs ''> <!ENTITY % attributeAttrs ''> <!ENTITY % attributeGroupAttrs ''> <!ENTITY % uniqueAttrs ''> <!ENTITY % keyAttrs ''> <!ENTITY % keyrefAttrs ''> <!ENTITY % selectorAttrs ''> <!ENTITY % fieldAttrs ''> <!ENTITY % assertAttrs ''>
<!ENTITY % includeAttrs ''> <!ENTITY % importAttrs ''> <!ENTITY % redefineAttrs ''> <!ENTITY % overrideAttrs ''> <!ENTITY % notationAttrs ''> <!ENTITY % annotationAttrs ''> <!ENTITY % appinfoAttrs ''> <!ENTITY % documentationAttrs ''>
<!ENTITY % complexDerivationSet "CDATA"> <!-- #all or space-separated list drawn from derivationChoice --> <!ENTITY % blockSet "CDATA"> <!-- #all or space-separated list drawn from derivationChoice + 'substitution' -->
<!ENTITY % composition '%include; | %import; | %override; | %redefine;'> <!ENTITY % mgs '%all; | %choice; | %sequence;'> <!ENTITY % cs '%choice; | %sequence;'> <!ENTITY % formValues '(qualified|unqualified)'>
<!ENTITY % attrDecls '((%attribute;| %attributeGroup;)*,(%anyAttribute;)?)'>
<!ENTITY % assertions '(%assert;)*'>
<!ENTITY % particleAndAttrs '(%openContent;?, (%mgs; | %group;)?, %attrDecls;, %assertions;)'>
<!-- This is used in part2 --> <!ENTITY % restriction1 '(%openContent;?, (%mgs; | %group;)?)'>
%xs-datatypes;
<!-- the duplication below is to produce an unambiguous content model which allows annotation everywhere --> <!ELEMENT %schema; ((%composition; | %annotation;)*, (%defaultOpenContent;, (%annotation;)*)?, ((%simpleType; | %complexType; | %element; | %attribute; | %attributeGroup; | %group; | %notation; ), (%annotation;)*)* )> <!ATTLIST %schema; targetNamespace %URIref; #IMPLIED version CDATA #IMPLIED %nds; %URIref; #FIXED 'http://www.w3.org/2001/XMLSchema' xmlns CDATA #IMPLIED finalDefault %complexDerivationSet; '' blockDefault %blockSet; '' id ID #IMPLIED elementFormDefault %formValues; 'unqualified' attributeFormDefault %formValues; 'unqualified' defaultAttributes CDATA #IMPLIED xpathDefaultNamespace CDATA '##local' xml:lang CDATA #IMPLIED %schemaAttrs;> <!-- Note the xmlns declaration is NOT in the schema for schema documents, because at the Infoset level where schemas operate, xmlns(:prefix) is NOT an attribute! --> <!-- The declaration of xmlns is a convenience for schema authors --> <!-- The id attribute here and below is for use in external references from non-schemas using simple fragment identifiers. It is NOT used for schema-to-schema reference, internal or external. -->
<!ELEMENT %defaultOpenContent; ((%annotation;)?, %any;)> <!ATTLIST %defaultOpenContent; appliesToEmpty (true|false) 'false' mode (interleave|suffix) 'interleave' id ID #IMPLIED %defaultOpenContentAttrs;>
<!-- a type is a named content type specification which allows attribute declarations--> <!-- -->
<!ELEMENT %complexType; ((%annotation;)?, (%simpleContent;|%complexContent;| %particleAndAttrs;))>
<!ATTLIST %complexType; name %NCName; #IMPLIED id ID #IMPLIED abstract %boolean; #IMPLIED final %complexDerivationSet; #IMPLIED block %complexDerivationSet; #IMPLIED mixed (true|false) 'false' defaultAttributesApply %boolean; 'true' %complexTypeAttrs;>
<!-- particleAndAttrs is shorthand for a root type --> <!-- mixed is disallowed if simpleContent, overridden if complexContent has one too. -->
<!-- If anyAttribute appears in one or more referenced attributeGroups and/or explicitly, the intersection of the permissions is used -->
<!ELEMENT %complexContent; ((%annotation;)?, (%restriction;|%extension;))> <!ATTLIST %complexContent; mixed (true|false) #IMPLIED id ID #IMPLIED %complexContentAttrs;>
<!ELEMENT %openContent; ((%annotation;)?, (%any;)?)> <!ATTLIST %openContent; mode (none|interleave|suffix) 'interleave' id ID #IMPLIED %openContentAttrs;>
<!-- restriction should use the branch defined above, not the simple one from part2; extension should use the full model -->
<!ELEMENT %simpleContent; ((%annotation;)?, (%restriction;|%extension;))> <!ATTLIST %simpleContent; id ID #IMPLIED %simpleContentAttrs;>
<!-- restriction should use the simple branch from part2, not the one defined above; extension should have no particle -->
<!ELEMENT %extension; ((%annotation;)?, (%particleAndAttrs;))> <!ATTLIST %extension; base %QName; #REQUIRED id ID #IMPLIED %extensionAttrs;>
<!-- an element is declared by either: a name and a type (either nested or referenced via the type attribute) or a ref to an existing element declaration -->
<!ELEMENT %element; ((%annotation;)?, (%complexType;| %simpleType;)?, (%alternative;)*, (%unique; | %key; | %keyref;)*)> <!-- simpleType or complexType only if no type|ref attribute --> <!-- ref not allowed at top level --> <!ATTLIST %element; name %NCName; #IMPLIED id ID #IMPLIED ref %QName; #IMPLIED type %QName; #IMPLIED minOccurs %nonNegativeInteger; #IMPLIED maxOccurs CDATA #IMPLIED nillable %boolean; #IMPLIED substitutionGroup %QName; #IMPLIED abstract %boolean; #IMPLIED final %complexDerivationSet; #IMPLIED block %blockSet; #IMPLIED default CDATA #IMPLIED fixed CDATA #IMPLIED form %formValues; #IMPLIED targetNamespace %URIref; #IMPLIED %elementAttrs;> <!-- type and ref are mutually exclusive. name and ref are mutually exclusive, one is required --> <!-- In the absence of type AND ref, type defaults to type of substitutionGroup, if any, else xs:anyType, i.e. unconstrained --> <!-- default and fixed are mutually exclusive -->
<!ELEMENT %alternative; ((%annotation;)?, (%simpleType; | %complexType;)?) > <!ATTLIST %alternative; test CDATA #IMPLIED type %QName; #IMPLIED xpathDefaultNamespace CDATA #IMPLIED id ID #IMPLIED >
<!ELEMENT %group; ((%annotation;)?,(%mgs;)?)> <!ATTLIST %group; name %NCName; #IMPLIED ref %QName; #IMPLIED minOccurs %nonNegativeInteger; #IMPLIED maxOccurs CDATA #IMPLIED id ID #IMPLIED %groupAttrs;>
<!ELEMENT %all; ((%annotation;)?, (%element;| %group;| %any;)*)> <!ATTLIST %all; minOccurs (0 | 1) #IMPLIED maxOccurs (0 | 1) #IMPLIED id ID #IMPLIED %allAttrs;>
<!ELEMENT %choice; ((%annotation;)?, (%element;| %group;| %cs; | %any;)*)> <!ATTLIST %choice; minOccurs %nonNegativeInteger; #IMPLIED maxOccurs CDATA #IMPLIED id ID #IMPLIED %choiceAttrs;>
<!ELEMENT %sequence; ((%annotation;)?, (%element;| %group;| %cs; | %any;)*)> <!ATTLIST %sequence; minOccurs %nonNegativeInteger; #IMPLIED maxOccurs CDATA #IMPLIED id ID #IMPLIED %sequenceAttrs;>
<!-- an anonymous grouping in a model, or a top-level named group definition, or a reference to same -->
<!ELEMENT %any; (%annotation;)?> <!ATTLIST %any; namespace CDATA #IMPLIED notNamespace CDATA #IMPLIED notQName CDATA '' processContents (skip|lax|strict) 'strict' minOccurs %nonNegativeInteger; '1' maxOccurs CDATA '1' id ID #IMPLIED %anyAttrs;>
<!-- namespace is interpreted as follows: ##any - - any non-conflicting WFXML at all
##other - - any non-conflicting WFXML from namespace other than targetNamespace
##local - - any unqualified non-conflicting WFXML/attribute one or - - any non-conflicting WFXML from more URI the listed namespaces references
##targetNamespace ##local may appear in the above list, with the obvious meaning -->
<!-- notNamespace is interpreted as follows: ##local - - any unqualified non-conflicting WFXML/attribute one or - - any non-conflicting WFXML from more URI the listed namespaces references
##targetNamespace ##local may appear in the above list, with the obvious meaning -->
<!ELEMENT %anyAttribute; (%annotation;)?> <!ATTLIST %anyAttribute; namespace CDATA #IMPLIED notNamespace CDATA #IMPLIED notQName CDATA '' processContents (skip|lax|strict) 'strict' id ID #IMPLIED %anyAttributeAttrs;> <!-- namespace and notNamespace are interpreted as for 'any' above -->
<!-- simpleType only if no type|ref attribute --> <!-- ref not allowed at top level, name iff at top level --> <!ELEMENT %attribute; ((%annotation;)?, (%simpleType;)?)> <!ATTLIST %attribute; name %NCName; #IMPLIED id ID #IMPLIED ref %QName; #IMPLIED type %QName; #IMPLIED use (prohibited|optional|required) #IMPLIED default CDATA #IMPLIED fixed CDATA #IMPLIED form %formValues; #IMPLIED targetNamespace %URIref; #IMPLIED inheritable %boolean; #IMPLIED %attributeAttrs;> <!-- type and ref are mutually exclusive. name and ref are mutually exclusive, one is required --> <!-- default for use is optional when nested, none otherwise --> <!-- default and fixed are mutually exclusive --> <!-- type attr and simpleType content are mutually exclusive -->
<!-- an attributeGroup is a named collection of attribute decls, or a reference thereto --> <!ELEMENT %attributeGroup; ((%annotation;)?, (%attribute; | %attributeGroup;)*, (%anyAttribute;)?) > <!ATTLIST %attributeGroup; name %NCName; #IMPLIED id ID #IMPLIED ref %QName; #IMPLIED %attributeGroupAttrs;>
<!-- ref iff no content, no name. ref iff not top level -->
<!-- better reference mechanisms --> <!ELEMENT %unique; ((%annotation;)?, %selector;, (%field;)+)> <!ATTLIST %unique; name %NCName; #IMPLIED ref %QName; #IMPLIED id ID #IMPLIED %uniqueAttrs;>
<!ELEMENT %key; ((%annotation;)?, %selector;, (%field;)+)> <!ATTLIST %key; name %NCName; #IMPLIED ref %QName; #IMPLIED id ID #IMPLIED %keyAttrs;>
<!ELEMENT %keyref; ((%annotation;)?, %selector;, (%field;)+)> <!ATTLIST %keyref; name %NCName; #IMPLIED ref %QName; #IMPLIED refer %QName; #IMPLIED id ID #IMPLIED %keyrefAttrs;>
<!ELEMENT %selector; ((%annotation;)?)> <!ATTLIST %selector; xpath %XPathExpr; #REQUIRED xpathDefaultNamespace CDATA #IMPLIED id ID #IMPLIED %selectorAttrs;> <!ELEMENT %field; ((%annotation;)?)> <!ATTLIST %field; xpath %XPathExpr; #REQUIRED xpathDefaultNamespace CDATA #IMPLIED id ID #IMPLIED %fieldAttrs;>
<!-- co-constraint assertions --> <!ELEMENT %assert; ((%annotation;)?)> <!ATTLIST %assert; test %XPathExpr; #REQUIRED id ID #IMPLIED xpathDefaultNamespace CDATA #IMPLIED %assertAttrs;>
<!-- Schema combination mechanisms --> <!ELEMENT %include; (%annotation;)?> <!ATTLIST %include; schemaLocation %URIref; #REQUIRED id ID #IMPLIED %includeAttrs;>
<!ELEMENT %import; (%annotation;)?> <!ATTLIST %import; namespace %URIref; #IMPLIED schemaLocation %URIref; #IMPLIED id ID #IMPLIED %importAttrs;>
<!ELEMENT %redefine; (%annotation; | %simpleType; | %complexType; | %attributeGroup; | %group;)*> <!ATTLIST %redefine; schemaLocation %URIref; #REQUIRED id ID #IMPLIED %redefineAttrs;>
<!ELEMENT %override; ((%annotation;)?, ((%simpleType; | %complexType; | %group; | %attributeGroup;) | %element; | %attribute; | %notation;)*)> <!ATTLIST %override; schemaLocation %URIref; #REQUIRED id ID #IMPLIED %overrideAttrs;>
<!ELEMENT %notation; (%annotation;)?> <!ATTLIST %notation; name %NCName; #REQUIRED id ID #IMPLIED public CDATA #REQUIRED system %URIref; #IMPLIED %notationAttrs;>
<!-- Annotation is either application information or documentation --> <!-- By having these here they are available for datatypes as well as all the structures elements -->
<!ELEMENT %annotation; (%appinfo; | %documentation;)*> <!ATTLIST %annotation; %annotationAttrs;>
<!-- User must define annotation elements in internal subset for this to work --> <!ELEMENT %appinfo; ANY> <!-- too restrictive --> <!ATTLIST %appinfo; source %URIref; #IMPLIED id ID #IMPLIED %appinfoAttrs;> <!ELEMENT %documentation; ANY> <!-- too restrictive --> <!ATTLIST %documentation; source %URIref; #IMPLIED id ID #IMPLIED xml:lang CDATA #IMPLIED %documentationAttrs;>
<!NOTATION XMLSchemaStructures PUBLIC 'structures' 'http://www.w3.org/2001/XMLSchema.xsd' > <!NOTATION XML PUBLIC 'REC-xml-1998-0210' 'http://www.w3.org/TR/1998/REC-xml-19980210' >
<!-- In keeping with the XML Schema WG's standard versioning policy, this DTD will persist at the URI http://www.w3.org/2012/04/XMLSchema.dtd.
At the date of issue it can also be found at the URI http://www.w3.org/2009/XMLSchema/XMLSchema.dtd.
The schema document at that URI may however change in the future, in order to remain compatible with the latest version of XSD and its namespace. In other words, if XSD or the XML Schema namespace change, the version of this document at http://www.w3.org/2009/XMLSchema/XMLSchema.dtd will change accordingly; the version at http://www.w3.org/2012/04/XMLSchema.dtd will not change.
Previous dated (and unchanging) versions of this DTD include:
http://www.w3.org/2012/01/XMLSchema.dtd (XSD 1.1 Proposed Recommendation)
http://www.w3.org/2011/07/XMLSchema.dtd (XSD 1.1 Candidate Recommendation)
http://www.w3.org/2009/04/XMLSchema.dtd (XSD 1.1 Candidate Recommendation)
http://www.w3.org/2004/10/XMLSchema.dtd (XSD 1.0 Recommendation, Second Edition)
http://www.w3.org/2001/05/XMLSchema.dtd (XSD 1.0 Recommendation, First Edition)
--> A specification of the import of Unique Particle Attribution (§3.8.6.4) [Definition:] overlap They are both element declaration particles whose declarations have the same expanded name They are both element declaration particles and one of them has the same expanded name · · They are both global · · They are both wildcards, and any one of the following is true of the wildcard intersection of their {namespace constraint} Attribute Wildcard Intersection (§3.10.6.4) It has {variety} any It has {variety} not It has {variety} enumeration {namespaces} A content model will violate the unique attribution constraint if it contains two particles which · · are both in the {particles} choice all may · · {min occurs} {max occurs} Two particles may · · A precise formulation of this constraint can also be offered in terms of operations on finite-state automaton: transcribe the content model into an automaton in the usual way using epsilon transitions for optionality and unbounded maxOccurs, unfolding other numeric occurrence ranges and treating the heads of · · but This section defines identifiers for various versions of XSD, including versions defined in superseded drafts, to enable precise reference to versions when such reference is necessary. http://www.w3.org/XML/XMLSchema XSD http://www.w3.org/XML/XMLSchema/v1.0 XSD 1.0 http://www.w3.org/XML/XMLSchema/v1.1 XSD 1.1 http://www.w3.org/XML/XMLSchema/v1.0/1e XSD 1.0 First Edition http://www.w3.org/XML/XMLSchema/v1.0/2e XSD 1.0 Second Edition http://www.w3.org/XML/XMLSchema/v1.1/1e XSD 1.1 First Edition http://www.w3.org/XML/XMLSchema/v1.0/1e/19990506 XSD 1.0 in 6 May 1999 working draft http://www.w3.org/XML/XMLSchema/v1.0/1e/19990924 XSD 1.0 in 24 September 1999 working draft http://www.w3.org/XML/XMLSchema/v1.0/1e/19991105 XSD 1.0 in 5 November 1999 working draft http://www.w3.org/XML/XMLSchema/v1.0/1e/19991217 XSD 1.0 in 17 December 1999 working draft http://www.w3.org/XML/XMLSchema/v1.0/1e/20000225 XSD 1.0 in 25 February 2000 working draft http://www.w3.org/XML/XMLSchema/v1.0/1e/20000407 XSD 1.0 in 7 April 2000 working draft http://www.w3.org/XML/XMLSchema/v1.0/1e/20000922 XSD 1.0 in 22 September 2000 working draft http://www.w3.org/XML/XMLSchema/v1.0/1e/20001024 XSD 1.0 Candidate Recommendation (CR) http://www.w3.org/XML/XMLSchema/v1.0/1e/20010316 XSD 1.0 first Proposed Recommendation (PR) http://www.w3.org/XML/XMLSchema/v1.0/1e/20010330 XSD 1.0 second Proposed Recommendation (PR) http://www.w3.org/XML/XMLSchema/v1.0/1e/20010502 XSD 1.0 Recommendation http://www.w3.org/XML/XMLSchema/v1.0/2e/20040318 XSD 1.0 Second Edition Proposed Edited Recommendation (PER) http://www.w3.org/XML/XMLSchema/v1.0/2e/20041028 XSD 1.0 Second Edition Recommendation http://www.w3.org/XML/XMLSchema/v1.1/1e/20040716 XSD 1.1 in 16 July 2004 working draft http://www.w3.org/XML/XMLSchema/v1.1/1e/20050224 XSD 1.1 in 24 February 2005 working draft http://www.w3.org/XML/XMLSchema/v1.1/1e/20060116 XSD 1.1 in 16 January 2006 working draft http://www.w3.org/XML/XMLSchema/v1.1/1e/20060217 XSD 1.1 in 17 February 2006 working draft http://www.w3.org/XML/XMLSchema/v1.1/1e/20060330 XSD 1.1 in 30 March 2006 working draft http://www.w3.org/XML/XMLSchema/v1.1/1e/20060831 XSD 1.1 in 31 August 2006 working draft http://www.w3.org/XML/XMLSchema/v1.1/1e/20070830 XSD 1.1 in 30 August 2007 working draft http://www.w3.org/XML/XMLSchema/v1.1/1e/20080620 XSD 1.1 in 20 June 2008 working draft http://www.w3.org/XML/XMLSchema/v1.1/1e/20090130 XSD 1.1 in 30 January 2009 working draft http://www.w3.org/XML/XMLSchema/v1.1/1e/20090430 XSD 1.1 Candidate Recommendation, 30 April 2009 http://www.w3.org/XML/XMLSchema/v1.1/1e/20091203 XSD 1.1 in working draft of 3 December 2009 http://www.w3.org/XML/XMLSchema/v1.1/1e/20110721 XSD 1.1 in Candidate Recommendation draft of 21 July 2011 http://www.w3.org/XML/XMLSchema/v1.1/1e/20120119 XSD 1.1 in Proposed Recommendation of 19 January 2012 http://www.w3.org/XML/XMLSchema/v1.1/1e/20120405 XSD 1.1 in Recommendation of 5 April 2012 The following documents, in whole or in part, contain provisions which must be consulted in order to understand fully or to implement some of the normative provisions of this specification. World Wide Web Consortium. XQuery 1.0 and XPath 2.0 Functions and Operators (Second Edition) http://www.w3.org/TR/xpath-functions/ The edition cited is the one current at the date of publication of this specification. Implementations may Bradner, Scott. RFC 2119: Key words for use in RFCs to Indicate Requirement Levels. http://www.ietf.org/rfc/rfc2119.txt World Wide Web Consortium. Namespaces in XML 1.0 (Third Edition) http://www.w3.org/TR/xml-names/ The edition cited is the one current at the date of publication of this specification. Implementations may Dependencies on Other Specifications (§1.4) World Wide Web Consortium. XQuery 1.0 and XPath 2.0 Data Model (XDM) (Second Edition) http://www.w3.org/TR/xpath-datamodel/ The edition cited is the one current at the date of publication of this specification. Implementations may World Wide Web Consortium. Extensible Markup Language (XML) 1.0 (Fifth Edition) http://www.w3.org/TR/xml/ The edition cited is the one current at the date of publication of this specification. Implementations may Dependencies on Other Specifications (§1.4) World Wide Web Consortium. Extensible Markup Language (XML) 1.1 (Second Edition) http://www.w3.org/TR/xml11/ The edition cited is the one current at the date of publication of this specification. Implementations may Dependencies on Other Specifications (§1.4) World Wide Web Consortium. XML Information Set (Second Edition) http://www.w3.org/TR/xml-infoset/ The edition cited is the one current at the date of publication of this specification. Implementations may World Wide Web Consortium. Namespaces in XML 1.1 (Second Edition) http://www.w3.org/TR/xml-names11/ The edition cited is the one current at the date of publication of this specification. Implementations may Dependencies on Other Specifications (§1.4) World Wide Web Consortium. XML Schema Version 1.1 Part 2: Datatypes http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/datatypes.html The edition cited is the one current at the date of publication of this specification. Implementations may World Wide Web Consortium. XML Path Language 2.0 (Second Edition) (Link errors corrected 3 January 2011) http://www.w3.org/TR/xpath20/ The edition cited is the one current at the date of publication of this specification. Implementations may World Wide Web Consortium. XSL Transformations (XSLT) Version 2.0 http://www.w3.org/TR/xslt20/ The edition cited is the one current at the date of publication of this specification. Implementations may Brüggemann-Klein, Anne, and Derick Wood. One-Unambiguous Regular Languages Information and Computation Bray, Tim, Charles Frankston, and Ashok Malhotra, ed., Document Content Description for XML (DCD) http://www.w3.org/TR/1998/NOTE-dcd-19980731 Bourret, Ronald, et al., ed., Document Definition Markup Language (DDML) Specification, Version 1.0 http://www.w3.org/TR/1999/NOTE-ddml-19990119 World Wide Web Consortium. Requirements for XML Schema 1.1 http://www.w3.org/TR/xmlschema-11-req/ The Rule of Least Power http://www.w3.org/2001/tag/doc/leastPower.html Fuchs, Matthew, Murray Maloney, and Alex Milowski. Schema for Object-oriented XML http://www.w3.org/TR/1998/NOTE-SOX-19980930/ Davidson, Andrew, et al. Schema for Object-oriented XML 2.0 http://www.w3.org/TR/NOTE-SOX/ Marinelli, Paolo, Claudio Sacerdoti Coen, and Fabio Vitali. SchemaPath, a Minimal Extension to XML Schema for Conditional Constraints Proceedings of the Thirteenth International World Wide Web Conference http://dl.acm.org/citation.cfm?doid=988672.988695 World Wide Web Consortium. User Agent Accessibility Guidelines 1.0 http://www.w3.org/TR/UAAG10/ World Wide Web Consortium. User Agent Accessibility Guidelines (UAAG) 2.0 http://www.w3.org/TR/UAAG20/ Frankston, Charles, and Henry S. Thompson. XML-Data Reduced ["This note is a refinement of the January 1998 XML-Data submission http://www.w3.org/TR/1998/NOTE-XML-data-0105/."] http://www.ltg.ed.ac.uk/~ht/XMLData-Reduced.htm World Wide Web Consortium. XML Schema Requirements http://www.w3.org/TR/NOTE-xml-schema-req World Wide Web Consortium. XML Schema: Component Designators http://www.w3.org/TR/xmlschema-ref/ World Wide Web Consortium. XML Schema Part 0: Primer Second Edition http://www.w3.org/TR/xmlschema-0/ Layman, Andrew, et al. XML-Data [A submission to W3C by Microsoft, ArborText, DataChannel, and Inso.] http://www.w3.org/TR/1998/NOTE-XML-data-0105/ World Wide Web Consortium. XML Path Language http://www.w3.org/TR/xpath/ XPointer Framework http://www.w3.org/TR/xptr-framework/ World Wide Web Consortium. XML Schema Part 1: Structures Second Edition http://www.w3.org/TR/xmlschema-1/ The following contributed material to version 1.0 of this specification: David Fallside, IBM The Working Group thanks the members of other W3C Working Groups and industry experts in other forums who have contributed directly or indirectly to the creation of this document and its predecessor. Since version 1.0 of this specification was completed, David Beech and Noah Mendelsohn have retired from the corporations which supported their work as editors. The email addresses given for them are those known at the time this document was published. The work of C. M. Sperberg-McQueen as a co-editor of this specification was supported by the World Wide Web Consortium through January 2009 and again from June 2010 through May 2011, and from February 2009 to the present by Black Mesa Technologies LLC. At the time this document is published, the members in good standing of the XML Schema Working Group are: David Ezell, National Association of Convenience Stores (NACS) ( chair Shudi (Sandy) Gao 高殊镝, IBM Mary Holstege, Mark Logic Sam Idicula, Oracle Corporation Michael Kay, Invited expert Jim Melton, Oracle Corporation Dave Peterson, Invited expert Liam Quin, W3C ( staff contact C. M. Sperberg-McQueen, invited expert Henry S. Thompson, University of Edinburgh Kongyi Zhou, Oracle Corporation The XML Schema Working Group has benefited in its work from the participation and contributions of a number of people who are no longer members of the Working Group in good standing at the time of publication of this Working Draft. Their names are given below. In particular we note with sadness the accidental death of Mario Jeckle shortly before publication of the first Working Draft of XML Schema 1.1. Affiliations given are (among) those current at the time of the individuals' work with the WG. Paula Angerstein, Vignette Corporation Leonid Arbouzov, Sun Microsystems Jim Barnette, Defense Information Systems Agency (DISA) David Beech, Oracle Corp. Gabe Beged-Dov, Rogue Wave Software Laila Benhlima, Ecole Mohammadia d'Ingenieurs Rabat (EMI) Doris Bernardini, Defense Information Systems Agency (DISA) Paul V. Biron, HL7; Invited expert Don Box, DevelopMentor Allen Brown, Microsoft Lee Buck, TIBCO Extensibility Greg Bumgardner, Rogue Wave Software Dean Burson, Lotus Development Corporation Charles E. Campbell, Invited expert Oriol Carbo, University of Edinburgh Wayne Carr, Intel Peter Chen, Bootstrap Alliance and LSU Tyng-Ruey Chuang, Academia Sinica Tony Cincotta, NIST David Cleary, Progress Software Mike Cokus, MITRE Dan Connolly, W3C ( staff contact Ugo Corda, Xerox Roger L. Costello, MITRE Joey Coyle, Health Level Seven Haavard Danielson, Progress Software Josef Dietl, Mozquito Technologies Kenneth Dolson, Defense Information Systems Agency (DISA) Andrew Eisenberg, Progress Software Rob Ellman, Calico Commerce Tim Ewald, Developmentor Alexander Falk, Altova GmbH David Fallside, IBM George Feinberg, Object Design Dan Fox, Defense Logistics Information Service (DLIS) Charles Frankston, Microsoft Matthew Fuchs, Commerce One Andrew Goodchild, Distributed Systems Technology Centre (DSTC Pty Ltd) Xan Gregg, TIBCO Extensibility Paul Grosso, Arbortext, Inc Martin Gudgin, DevelopMentor Ernesto Guerrieri, Inso Dave Hollander, Hewlett-Packard Company ( co-chair Nelson Hung, Corel Jane Hunter, Distributed Systems Technology Centre (DSTC Pty Ltd) Michael Hyman, Microsoft Renato Iannella, Distributed Systems Technology Centre (DSTC Pty Ltd) Mario Jeckle, DaimlerChrysler Rick Jelliffe, Academia Sinica Marcel Jemio, Data Interchange Standards Association Simon Johnston, Rational Software Kohsuke Kawaguchi, Sun Microsystems Dianne Kennedy, Graphic Communications Association Janet Koenig, Sun Microsystems Setrag Khoshafian, Technology Deployment International (TDI) Melanie Kudela, Uniform Code Council Ara Kullukian, Technology Deployment International (TDI) Andrew Layman, Microsoft Dmitry Lenkov, Hewlett-Packard Company Bob Lojek, Mozquito Technologies John McCarthy, Lawrence Berkeley National Laboratory Matthew MacKenzie, XML Global Nan Ma, China Electronics Standardization Institute Eve Maler, Sun Microsystems Ashok Malhotra, IBM; Microsoft; Oracle Murray Maloney, Muzmo Communication, acting for Commerce One Paolo Marinelli, University of Bologna Lisa Martin, IBM Noah Mendelsohn, Lotus, IBM, invited expert Adrian Michel, Commerce One Alex Milowski, Invited expert Don Mullen, TIBCO Extensibility Ravi Murthy, Oracle Murata Makoto, Xerox Chris Olds, Wall Data Frank Olken, Lawrence Berkeley National Laboratory David Orchard, BEA Systems, Inc. Paul Pedersen, Mark Logic Corporation Shriram Revankar, Xerox Mark Reinhold, Sun Microsystems Jonathan Robie, Software AG Cliff Schmidt, Microsoft John C. Schneider, MITRE Eric Sedlar, Oracle Corp. Lew Shannon, NCR Anli Shundi, TIBCO Extensibility William Shea, Merrill Lynch Jerry L. Smith, Defense Information Systems Agency (DISA) John Stanton, Defense Information Systems Agency (DISA) Tony Stewart, Rivcom Bob Streich, Calico Commerce William K. Stumbo, Xerox Hoylen Sue, Distributed Systems Technology Centre (DSTC Pty Ltd) Ralph Swick, W3C John Tebbutt, NIST Ross Thompson, Contivo Matt Timmermans, Microstar Jim Trezzo, Oracle Corp. Steph Tryphonas, Microstar Scott Tsao, The Boeing Company Mark Tucker, Health Level Seven Asir S. Vedamuthu, webMethods, Inc Fabio Vitali, University of Bologna Scott Vorthmann, TIBCO Extensibility Priscilla Walmsley, XMLSolutions Norm Walsh, Sun Microsystems Cherry Washington, Defense Information Systems Agency (DISA) Aki Yoshida, SAP AG Stefano Zacchiroli, University of Bologna Mohamed Zergaoui, Innovimax