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 become a ↑ Last Call Public Working Draft of 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 some errors in XSD 1.0, and clarifies some wording. ↑ This draft was created on 8 February 2008. It reflects (unless otherwise noted elsewhere) all decisions on this document made by the Working Group through 8 February 2008. The document thus incorporates all decisions made by the Working Group to date. ↑

This draft was published on 8 February 2008. The major revisions since the previous draft include:

A mechanism for conditional type assignment has been defined; this allows the ·governing type definition· to be assigned by evaluating information in the instance document.
Element declarations may now specify multiple substitution group heads.
A default attribute group may now be specified at the schema-document level; all complex types defined in the schema document will include that attribute group unless they specify otherwise; this makes it easier to specify that particular attributes are to be accepted by every complex type in a schema.
Content models may now be defined as "open", which means that elements other than those explicitly named will be accepted during validation. Several styles and degrees of openness are possible; they can be configured at the level of the schema document or of the complex type definition.
Wildcards may now be defined which match only elements not declared in the schema (so-called "not-in-schema" wildcards).
Complex types whose content models are all-groups may now be extended. (This change is in addition to other changes in all-groups described in Changes since version 1.0 (§G).)
The assertions facility defined in the previous working draft has been revised; the report element has been dropped and the rules for evaluation of XPath expressions have been made more explicit. These changes may help minimize confusion between the assertions defined here and the assert and report elements of Schematron, which can still be used in <appinfo> elements, or separately.
Elements may now have more than one attribute of type xs:ID.
Various enhancements to the definition of the ·post-schema-validation infoset· have been made. These include the definition of some new properties to support new features (e.g. [type alternative] to support conditional type assignment) and new rules for assigning values to existing properties (the [type definition], for example, is now defined whenever the ·governing type definition· is known, instead of being undefined if the element is invalid).
Some aspects of the use of xsi:type have been clarified.
A conditional-inclusion mechanism has been defined to allow XSD 1.1 processors to cope more successfully with constructs defined in future versions of this specification, if any. Schema authors can use this mechanism to define alternative constructs depending on the version of the processor, so that the same schema document can be usable with processors supporting different versions of XSD.
Numerous editorial changes and small bug fixes have been made in the interests of clarity and correctness.

For those primarily interested in the changes since version 1.0, the appendix Changes since version 1.0 (§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 8 November 2007. 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 should be considered a "feature at risk": the feature may be retained as is, modified, or dropped, depending on the feedback received from readers, schema authors, schema users, and implementors.

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

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

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

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

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

...

2 Conceptual Framework

...

2.2 XSD Abstract Data Model

        2.2.1 Type Definition Components
            2.2.1.1 Type Definition Hierarchy
            2.2.1.2 Simple Type Definition
            2.2.1.3 Complex Type Definition
        2.2.2 Declaration Components
            2.2.2.1 Element Declaration
            2.2.2.2 Element Substitution Group
            2.2.2.3 Attribute Declaration
            2.2.2.4 Notation Declaration
        2.2.3 Model Group Components
            2.2.3.1 Model Group
            2.2.3.2 Particle
            2.2.3.3 Attribute Use
            2.2.3.4 Wildcard
        2.2.4 Constraint Components
            2.2.4.1 Identity-constraint Definition
            2.2.4.2 Type Alternative
            2.2.4.3 Assertion
        2.2.5 Group Definition Components
            2.2.5.1 Model Group Definition
            2.2.5.2 Attribute Group Definition
        2.2.6 Annotation Components

...

2.2.2 Declaration Components

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.

2.2.2.1 Element Declaration

...

2.2.2.2 Element Substitution Group

In XML, the name and content of an element must correspond exactly to the element type referenced in the corresponding content model.

[Definition:] Through the new mechanism of element substitution groups, XSD provides a more powerful model supporting substitution of one named element for another. Any top-level element declaration can serve as the defining member, or head, for an element ·substitution group·. Other top-level element declarations, regardless of target namespace, can be designated as members of the ·substitution group· headed by this element. In a suitably enabled content model, a reference to the head ·validates· not just the head itself, but elements corresponding to any other member of the ·substitution group· as well.

All such members must have type definitions which are either the same as the head's type definition or ↓restrictions or extensions of↓↑derived from↑ it. Therefore, although the names of elements can vary widely as new namespaces and members of the ·substitution group· are defined, the content of member elements is ↓strictly limited according to↓↑constrained by↑ the type definition of the ·substitution group· head.

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)).

...

2.2.3 Model Group Components

The model group, particle, and wildcard components contribute to the portion of a complex type definition that controls an element information item's content.

2.2.3.1 Model Group

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 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 may be written L(G). [Definition:] A model group G↑ ↑is said to accept or recognize the members of L(G).

For detailed information on model groups, see Model Groups (§3.8).

...

3 Schema Component Details

...

3.3 Element Declarations

...

3.3.5 Element Declaration Information Set Contributions

...

3.3.5.4 Element Validated by Type

Schema Information Set Contribution: Element Validated by Type

If and only if ↓and only if↓ a ·governing type definition· is known for an element information item, then in the ·post-schema-validation infoset· the item has the properties:

PSVI Contributions for element information items

[schema normalized value]

The appropriate case among the following:

1 If clause 3.2 of Element Locally Valid (Element) (§3.3.4.3) above has not applied and either the ·governing type definition· is a simple type definition or its {content type} has {variety} simple, then the appropriate case among the following:

1.1 If clause 5.1 of Element Locally Valid (Element) (§3.3.4.3) above has applied, then the {lexical form} of the {value constraint}

1.2 If clause 5.1 of Element Locally Valid (Element) (§3.3.4.3) above has not applied and the the element's ·normalized value· is ·valid· with respect to the simple type definition as defined by String Valid (§3.16.4), then the ·normalized value· of the item as ·validated·

1.3 otherwise ·absent·.

2 otherwise ·absent·.

[schema actual value]

If the [schema normalized value] is not ·absent·, then the corresponding ·actual value· ; otherwise ·absent·.

[type definition]

An ·item isomorphic· to the ·governing type definition· component itself.

[type definition type]

simple or complex, depending on the ·type definition·.

[type definition namespace]

The {target namespace} of the ·type definition·.

[type definition anonymous]

true if the {name} of the ·type definition· is ·absent·, otherwise false.

[type definition name]

The {name} of the ·type definition·, if the {name} is not ·absent·. If the ·type definition·'s {name} property is ·absent·, schema processors may, but need not, provide a value unique to the definition. It is ·implementation-defined· whether a processor provides a name for such a type definition. If a processor does provide a value in this situation, the choice of what value to use is ·implementation-dependent·.

[type fallback]

A keyword indicating whether the expected type definition was unavailable and the element had a fallback type as its ·governing type definition·

declared if the element information item has a ·governing element declaration· which has no {type table}, and also an xsi:type attribute which fails to ·resolve· to a type definition that ·overrides· the declared {type definition}
selected if the element information item has a ·governing element declaration· with a {type table} and also has an xsi:type attribute which fails to ·resolve· to a type definition that ·overrides· the ·selected type definition·
lax if the element was ·laxly assessed· using ·xs:anyType·
none otherwise

[type alternative]

If the element's ·governing element declaration· does not have a {type table}, then ·absent·; otherwise the first Type Alternative that ·successfully selected· the element's ·selected type definition·, if any; otherwise the {default type definition}.

[local type validity]

The appropriate case among the following:

1 If the element information item was ·valid· as defined by Element Locally Valid (Type) (§3.3.4.4), then valid

2 otherwise (the item was ·invalid· as defined by Element Locally Valid (Type) (§3.3.4.4)) invalid.

[descendent validity]

The appropriate case among the following:

1 If neither its [children] nor its [attributes] contains an information item I (element or attribute respectively) where either I's [validity] is invalid or I is ·attributed· to a strict ·wildcard particle· and I's [validity] is notKnown , then valid;

2 otherwise invalid.

Note: The [type definition type], [type definition namespace], [type definition name], and [type definition anonymous] properties are redundant with the [type definition] property; they are defined for the convenience of implementations which wish to expose those specific properties but not the entire type definition.

Note: When clause 5.1 of Element Locally Valid (Element) (§3.3.4.3) above applies and the default or fixed value constraint {value} is of type QName or NOTATION, it is ·implementation-dependent· whether ·namespace fixup· occurs; if it does not, the prefix used in the lexical representation (in [schema normalized value]) will not necessarily map to the namespace name of the value (in [schema actual value]). To reduce problems and confusion, users may prefer to ensure that the required namespace information item is present in the input infoset.

...

3.13 Assertions

        3.13.1 The Assertion Schema Component
        3.13.2 XML Representation of Assertion Schema Components
        3.13.3 Constraints on XML Representations of Assertions
        3.13.4 Assertion Validation Rules
            3.13.4.1 Assertion Satisfied
            3.13.4.2 XPath Evaluation
        3.13.5 Assertion Information Set Contributions
        3.13.6 Constraints on Assertion Schema Components
            3.13.6.1 Assertion Properties Correct
            3.13.6.2 Test Value OK
            3.13.6.3 XPath Valid

...

3.13.6 Constraints on Assertion Schema Components

All assertions (see Assertions (§3.13)) must satisfy the following constraints.

3.13.6.1 Assertion Properties Correct

Schema Component Constraint: Assertion Properties Correct

The values of the properties of an assertion must be as described in the property tableau in The Assertion Schema Component (§3.13.1), modulo the impact of Missing Sub-components (§5.3).

3.13.6.2 Test Value OK

Schema Component Constraint: Test Value OK

Note: This constraint imposes distinct obligations on conforming schemas and on conforming processors.

An XPath expression in a conforming schema must, if governed by this constraint, satisfy Schema Component Constraint XPath Valid (§3.13.6.3).

Note: The {test} properties of Assertion and the {test} properties of Type Alternatives are governed by this constraint, as are any other properties whose definitions require that they satisfy this constraint. The XPath expressions used in identity constraints are not governed by this constraint.

A conforming processor must accept and process any XPath expression conforming to the "required subset" of [XPath 2.0] defined by the following grammar.

Note: Any XPath expression valid according to [XPath 2.0] may appear in a conforming schema. Conforming processors may but are not required to support XPath expressions not belonging to the required subset of XPath.

An XPath expression belongs to the required subset of XPath if and only if all of the following are true:

1 The {expression} property of the XPath Expression is a valid XPath expression, as defined in [XPath 2.0].

2 One of the following must be true:

2.1 It conforms to the following extended BNF:

Test XPath expressions

[9]	`Test`	::=	`ExprSingle`
[10]	`ExprSingle`	::=	`QuantifiedExpr \| IfExpr \| OrExpr`
[11]	`QuantifiedExpr`	::=	`("some" \| "every") "$" VarName "in" ValueExpr ("," "$" VarName "in" ValueExpr)* "satisfies" ExprSingle`
[12]	`VarName`	::=	`QName`
[13]	`IfExpr`	::=	`"if" "(" ExprSingle ")" "then" ExprSingle "else" ExprSingle`
[14]	`OrExpr`	::=	`AndExpr ( 'or' AndExpr )*`
[15]	`AndExpr`	::=	`BooleanExpr ( 'and' BooleanExpr )*`
[16]	`BooleanExpr`	::=	`'(' ExprSingle ')' \|`
			`BooleanFunction \|`
			`( ValueFunction \| SimpleValue) Comparator ValueExpr \|`
			`UnionExpr ( Comparator ValueExpr )?`
[17]	`BooleanFunction`	::=	`QName '(' ( ExprSingle ( ',' ExprSingle )* )? ')'`
[18]	`Comparator`	::=	`↓'=' \| '!=' \| '<' \| '<=' \| '>' \| '>='↓ ↑'eq' \| 'ne' \| 'lt' \| 'le' \| 'gt' \| 'ge'↑`
[19]	`ValueExpr`	::=	`ValueFunction \| SimpleValue \| UnionExpr`
[20]	`ValueFunction`	::=	`QName '(' ValueExpr? ')'`
[21]	`SimpleValue`	::=	`ConstructorFunction \| StringLiteral \| IntegerLiteral`
[22]	`ConstructorFunction`	::=	`QName '(' StringLiteral ')'`
[23]	`StringLiteral`	::=	`('"' (EscapeQuot \| [^"])* '"') \| ("'" (EscapeApos \| [^'])* "'")`
[24]	`IntegerLiteral`	::=	`[\-+]?[0-9]+`
[25]	`EscapeQuot`	::=	`'""'`
[26]	`EscapeApos`	::=	`"''"`
[27]	`UnionExpr`	::=	`PathExpr ( '\|' PathExpr )*`
[28]	`PathExpr`	::=	`('.//')? ( StepExpr '/' )* ( StepExpr \| '@' NameTest)`
[29]	`StepExpr`	::=	`('.' \| NameTest ) ( '[' PredicateExpr ']' )*`
[30]	`PredicateExpr`	::=	`ExprSingle \| PositionLiteral`
[31]	`PositionLiteral`	::=	`[0-9]+`

2.2 It is an XPath expression involving the child and/or attribute axes whose abbreviated form is as given above.

Note: For readability, [XPath 2.0] allows whitespace to be used between tokens in XPath expressions, even though this is not explicitly shown in the grammar. For details of whitespace handling, consult [XPath 2.0].

3 If part of the restricted XPath matches QName in the BooleanFunction production, then it identifies one of the following functions defined in the [Functions and Operators] specification: fn:true, fn:false and fn:not.

4 If part of the restricted XPath matches QName in the ValueFunction production production, then it identifies one of the following functions defined in the [Functions and Operators] specification: fn:data, fn:local-name, fn:namespace-uri, fn:count, fn:max and fn:min.

5 If part of the restricted XPath matches the ConstructorFunction production, then all of the following are true:

5.1 The piece that matches QName identifies a simple type definition.

5.2 The ·normalized value· of the piece that matches StringLiteral is locally ·valid· with respect to the simple type definition identified in the above step, as per String Valid (§3.16.4).

Note: Implementations may choose to support a bigger subset of [XPath 2.0].

Note: The definition of PredicateExpr given above may be more general than is desirable.

Editorial Note: Priority Feedback Request

Earlier drafts of this specification defined a more restricted form of the non-terminal PredicateExpr (shown below). The XML Schema Working Group is not certain whether to retain the more comprehensive definition given above in the required minimum subset of XPath which all processors must implement, or to return to the earlier restricted form. The Working Group solicits input from implementors and users on this issue.

Alternate definition of Predicate Expressions

[32]	`PredicateExpr`	::=	`PredicateOr \| PositionLiteral`
[33]	`PredicateOr`	::=	`PredicateAnd ( 'or' PredicateAnd )*`
[34]	`PredicateAnd`	::=	`PredicateBoolean ( 'and' PredicateBoolean )*`
[35]	`PredicateBoolean`	::=	`'(' PredicateOr ')'`
			`\| PBooleanFunction`
			`\| ( PValueFunction \| ConstructorFunction ) Comparator PredicateValue`
			`\| '@' NameTest ( Comparator PredicateValue )?`
[36]	`PBooleanFunction`	::=	`QName '(' PredicateOr? ( ',' PredicateOr )* ')'`
[37]	`PValueFunction`	::=	`QName '(' PredicateValue? ')'`
[38]	`PredicateValue`	::=	`ConstructorFunction \| '.' \| '@' NameTest`

...

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

Editor's Draft 8 February 2008

Status of this Document

Table of Contents

Appendices

2 Conceptual Framework

2.2 XSD Abstract Data Model

2.2.2 Declaration Components

2.2.2.1 Element Declaration

2.2.2.2 Element Substitution Group

2.2.3 Model Group Components

2.2.3.1 Model Group

3 Schema Component Details

3.3 Element Declarations

3.3.5 Element Declaration Information Set Contributions

3.3.5.4 Element Validated by Type

3.13 Assertions

3.13.6 Constraints on Assertion Schema Components

3.13.6.1 Assertion Properties Correct

3.13.6.2 Test Value OK