W3C XML Schema Definition Language (XSD) 1.1 Part 1: Structures -- Review Version

Status of this Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This ↑is a member-only review version which will in due course be published as a↑ W3C Proposed Recommendation ↓specifies↓ ↑specifying↑ the W3C XML Schema Definition Language (XSD) 1.1. It ↑has no formal standing within W3C; it↑ is here made available for review by W3C members↓ and the public↓. XSD 1.1 retains all the essential features of XSD 1.0, but adds several new features to support functionality requested by users, fixes many errors in XSD 1.0, and clarifies wording. ↑ This draft was created on 21 April 2011. It reflects (unless otherwise noted elsewhere) all decisions on this document made by the Working Group through 18 March 2011. The document thus incorporates all decisions made by the Working Group to date. ↑

↑

It also includes the following proposal(s) for changes to the wording of the spec:

A wording proposal to resolve issue 12454 Incorrectly quoted word in explanatory note of "Override Constraints and Semantics" by changing the text to correct the sentence.

↑

This draft was published on 21 April 2011. The major revisions since the previous public working draft include the following:

Enumerations, value constraints, and identity constraints now accept either equal or identical values as the same. This change resolves issue 9196 Enumeration and NaN
Changes have been made in section Constraints on XML Representations of Simple Type Definitions (§3.16.3) and section Constraints on XML Representations of Complex Type Definitions (§3.4.3) to make explicit that XML representations of extension facets (facets in namespaces other than the Schema namespace) are allowed to appear more than once in restrictions of simple types. This resolves issue 11222 src-simple-type.1 should allow duplicate elements from "##other" namespaces.
The definition of Element Locally Valid (Type) (§3.3.4.4) has been changed to remove the rule that an element with an ·instance-specified type definition· cannot be locally valid against any type definition other than the one specified in the instance. This resolves issue 11764 Unresolved xsi:type should not affect validity against a type.
The text concerning xsi:type attributes and their effect has been clarified in Element Locally Valid (Element) (§3.3.4.3). In particular, the revisions attempt to make clearer just what happens in cases where the xsi:type attribute in the document instance cannot be used (because the type named is unknown, or otherwise not usable). This resolves issue 11219 Editorial revision of Element Locally Valid (Element).
The text has been revised to make clearer that declarations enclosed in an xs:override element are handled using the elementFormDefault and other schema-document-level defaults from the schema document being overridden, not the schema documnt containing the xs:override element. This resolves issue 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 type tables in Element Declarations Consistent (§3.8.6.3) has been made more specific; this resolves issue 11076 Element Declarations Consistent: comparing type tables.
A note has been added to the discussion of <override> elements to make it easier to see how processors are expected to handle cycles in references from one schema document to another. This change resolves issue 12184 Circularity in xs:override.
Some errors in the XSLT stylesheet of appendix Transformation for Chameleon Inclusion (§F.1) have been corrected (resolving issues 8573 F.1 Stylesheet for chameleons invalid and 8574 F.1 Stylesheet for chameleons incomplete).
In the DTD for schema documents (DTD for Schemas (non-normative) (§J)), an error has been corrected in the declaration of the inheritable attribute of the xs:attribute element (resolving issue 11070 DTD for schema documents: inheritable declared as %URIref).
In the schema for schema documents, an error in the declaration of xs:group within the named model group xs:allModel has been corrected to make the type of xs:all a legal restriction of its base type and make the schema for schema documents conformant to this specification. This resolves issue 11092 Error in S4SD: complexType name="all" is not a valid restriction.
The XPath subset for selectors and fields in section Selector Value OK (§3.11.6.2) and Fields Value OK (§3.11.6.3) has been revised to align its tokenization rules better with [XPath 2.0]; this resolves issue 8454 Tokens in XPath subset for selectors/fields.
The text has been revised to correct the terminology used to describe correct XPath expressions and to specify that it is ·implementation-defined· when type errors in XPath expressions are detected and whether they are treated as static or dynamic errors. This change resolves issue 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.
The text has been revised to ensure that the special validation rules for xs:ID, xs:IDREF, xs:IDREFS, xs:ENTITY, and xs:ENTITIES apply not only to the built-in types themselves but also to types derived from them by restriction, list construction, union, and extension. This resolves issue 10662 Should IDREFS and ENTITIES be magic types?.
Some passages have been recast for clarity.
Several 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) is the recommended starting point. It summarizes both changes made since XSD 1.0 and some changes which were expected (and predicted in earlier drafts of this specification) but have not been made after all. Accompanying versions of this document display in color all changes to normative text since version 1.0 and since the previous Working Draft.

The Last Call review period for this document extends until 31 December 2009. Comments on this document should be made in W3C's public installation of Bugzilla, specifying "XML Schema" as the product. Instructions can be found at http://www.w3.org/XML/2006/01/public-bugzilla. If access to Bugzilla is not feasible, please send your comments to the W3C XML Schema comments mailing list, www-xml-schema-comments@w3.org (archive) Each Bugzilla entry and email message should contain only one comment.

Although feedback based on any aspect of this specification is welcome, there are certain aspects of the design presented herein for which the Working Group is particularly interested in feedback. These are designated "priority feedback" aspects of the design, and identified as such in editorial notes at appropriate points in this draft. Any feature mentioned in a priority feedback note is a "feature at risk": the feature may be retained as is or dropped, depending on the feedback received from readers, schema authors, schema users, and implementors.

Publication as a ↓Proposed Recommendation↓↑Editors' Draft↑ does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

The W3C XML Schema Working Group intends to request advancement of this specification and publication as a Proposed Recommendation (bypassing the usual Candidate Recommendation phase) as soon after 31 December 2009 as the following conditions are met.

A test suite is available which tests each required and optional feature of XSD 1.1.
Each feature of the specification has been implemented successfully by at least two independent implementations.
The Working Group has responded formally to all issues raised against this document during the Candidate Recommendation period.

The expected Proposed Recommendation may include editorial changes and may possibly remove features identified in this draft as being at risk. At the time this Last Call Working Draft was published, no interoperability or implementation report had yet been prepared.

This document has been produced by the W3C XML Schema Working Group as part of the W3C XML Activity. The goals of XSD 1.1 are discussed in the document Requirements for XML Schema 1.1. The authors of this document are the members of the XML Schema Working Group. Different parts of this specification have different editors.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

The English version of this specification is the only normative version. Information about translations of this document is available at http://www.w3.org/2003/03/Translations/byTechnology?technology=xmlschema.

The presentation of this document has been augmented to identify changes from a previous version, controlled by dg-b12454.xml. Three kinds of changes are highlighted: ↑new, added text↑, ↑changed text↓, and ↓deleted text↓.

... ... ...

4 Schemas and Namespaces: Access and Composition

...

4.2 Layer 2: Schema Documents, Namespaces and Composition

        4.2.1 Basic concepts of schema construction and composition
        4.2.2 Conditional inclusion
        4.2.3 Assembling a schema for a single target namespace from multiple schema definition documents (<include>)
        4.2.4 Including modified component definitions (<redefine>)
        4.2.5 Overriding component definitions (<override>)
        4.2.6 References to schema components across namespaces (<import>)
            4.2.6.1 Licensing References to Components Across Namespaces
            4.2.6.2 Providing Hints for Imported Schema Document Locations

The sub-sections of Schema Component Details (§3) define an XML representation for type definitions and element declarations and so on, specifying their target namespace and collecting them into schema documents. The following sections describe how to assemble a complete schema from multiple sources.

Note: The core ·assessment· architecture requires that a complete schema with all the necessary declarations and definitions be available. This will sometimes involve resolving both instance → schema (or schema document) and schema-document → schema (or schema document) references. As observed earlier in Conformance (§2.4), the precise mechanisms for resolving such references are expected to evolve over time. In support of such evolution, this specification observes the design principle that references from one schema document to a schema use mechanisms that directly parallel those used to reference a schema from an instance document.

Note: In the sections below, "schemaLocation" really belongs at layer 3. For convenience, it is documented with the layer 2 mechanisms of import and include, with which it is closely associated.

... ... ... ...

4.2.5 Overriding component definitions (`<override>`)

...

Schema Representation Constraint: Override Constraints and Semantics

In addition to the conditions imposed on <override> element information items by the schema for schema documents all of the following also apply:

1 If the ·actual value· of the schemaLocation [attribute] successfully resolves one or more of the following is true:

1.1 It resolves to (a fragment of) a resource which is an XML document (see clause 1.1 of Inclusion Constraints and Semantics (§4.2.3)), which in turn corresponds to a <schema> element information item in a well-formed information set.

1.2 It resolves to a <schema> element information item in a well-formed information set.

In either case call the overridden <schema> item D_old and the overriding item's parent <schema> item D_new.

2 One of the following must be true:

2.1 D_old has a targetNamespace [attribute], and its ·actual value· is identical to the ·actual value· of the targetNamespace [attribute] of D_new (which must have such an [attribute]).

2.2 Neither D_old nor D_new have a targetNamespace [attribute].

2.3 D_old has no targetNamespace [attribute] (but D_new does).

3 The appropriate case among the following must be true:

3.1 If clause 2.1 or clause 2.2 above is satisfied, then

3.1.1 Let D_old′ be a <schema> information item obtained by performing on D_old the transformation specified in Transformation for xs:override (§F.2). Then D_old′ corresponds to a conforming schema (call it S_old).

3.1.2 The <override> element in schema document D_new pointing to D_old is replaced by an <include> element pointing to D_old′ and the inclusion is handled as described in Assembling a schema for a single target namespace from multiple schema definition documents (<include>) (§4.2.3).

Note: It is not necessary to perform a literal replacement of the <override> element in D_new with an <include> element; any implementation technique can be used as long as it produces the required result.

Note: One effect of the rule just given is that the schema corresponding to D_new includes not only definitions or declarations corresponding to the appropriate members of its own [children], but also components identical to all the ·schema components· of S_old (with the possible exception of the Schema component of S_old).

Note: Another effect is that if schema document A contains a source declaration for a component E, and schema document B overrides A with its own declaration for E, and schema document C in turn overrides B with a third declaration for E, then ↑in calculating schema(C)↑

3.1.2.1 First, the override of B by C is handled. The resulting schema document ↑(B′, a modified version of B)↑ still contains an <override> element referring to ↓C↓↑A↑, but the declaration for E contained in it has been replaced by that specified in C.

3.1.2.2 Then, the override of A by ↓(the modified version of) B↓ ↑B′ (the modified version of B)↑ is handled.

3.1.2.3 The resulting version of A, containing the declaration for E originally present in C, is included by ↓the modified version of B,↓ ↑B′,↑ which is itself included by C.

3.1.2.4 The resulting schema contains the version of E originally specified in schema document C.

(The references to "first" and ↓"next"↓↑"then"↑ here refer to the logical precedence of operations, not to a required order in which implementations are required to perform particular tasks.)

3.2 If clause 2.3 above is satisfied, then

3.2.1 Let D_old′ be a <schema> information item obtained by performing on D_old first the transformation specified in Transformation for Chameleon Inclusion (§F.1) and then the transformation specified in Transformation for xs:override (§F.2). Then D_old′ corresponds to a conforming schema (call it S2).

3.2.2 The <override> element in schema document D_new pointing to D_old is replaced by an <include> element pointing to D_old′ and the inclusion is handled as described in Assembling a schema for a single target namespace from multiple schema definition documents (<include>) (§4.2.3).

Note: The effect of applying the stylesheet in Transformation for xs:override (§F.2) is to make D_old′ identical to D_old except that some elements in D_old are replaced or modified, as described in Transformation for xs:override (§F.2). Implementations do not have to use [XSLT 2.0] transformation, as long as the same result is produced.

Note: It is D_old′ and not D_old, which is required to correspond to a conforming schema. In particular, it is not an error for D_old to fail to satisfy all of the constraints governing schema documents, while it is an error if D_old′ fails to satisfy them.

Note: The effect of override pre-processing is that any declarations and definitions contained within an <override> will be substituted for matching declarations and definitions within the target set; the resulting schema documents will then be processed normally, as described in the relevant portions of this specification. This has the effect that the rules for document-level defaults (elementFormDefault, attributeFormDefault, blockDefault, finalDefault, and so on) are applied not in the context of the document containing the <override> (D_new) but in the context of the document containing the original overridden declaration or definition (D_old). Unexpected results may be minimized if the children of an <override> are made independent of the document-level defaults by explicitly specifying the desired values for the properties in question.

Note: In <redefine>, components are allowed or required to refer to themselves. There is no similar special treatment in <override>. Overriding components are constructed as if the overridden components had never existed.

Note: The above is carefully worded so that multiple equivalent overrides of the same schema document will not constitute a violation of clause 2 of Schema Properties Correct (§3.17.6.1), but applications are allowed, indeed encouraged, to avoid overriding the same schema document in the same way more than once to forestall the necessity of establishing identity component by component.

Note: It is a consequence of the semantics of inclusion, as defined in Inclusion Constraints and Semantics (§4.2.3) (in particular clause 3.1.2 and clause 3.2.2); redefinition, as defined in Including modified component definitions (<redefine>) (§4.2.4); import, as defined in References to schema components across namespaces (<import>) (§4.2.6); and overriding, as defined in this section, that if the same schema document is both (a) included, imported, or redefined, and (b) non-vacuously overridden, or if the same schema document overridden twice in different ways, then the resulting schema will have duplicate and conflicting versions of some components and will not be conforming, just as if two different schema documents had been included, with different declarations for the same ·named· components.

...

W3C XML Schema Definition Language (XSD) 1.1 Part 1: Structures

Editor's Draft 21 April 2011

Status of this Document

4 Schemas and Namespaces: Access and Composition

4.2 Layer 2: Schema Documents, Namespaces and Composition

4.2.5 Overriding component definitions (<override>)

4.2.5 Overriding component definitions (`<override>`)