Movatterモバイル変換

The·actual value· of thename[attribute]

The·actual value· of thetargetNamespace[attribute] of the parent<schema> element information item, or·absent· if there is none.

The simple typedefinition corresponding to the<simpleType>element informationitem in the[children], if present, otherwise the simpletype definition·resolved· to by the·actual value· of thetype[attribute], if present, otherwise·xs:anySimpleType·.

AScope as follows:

Property

Value

global

If there is adefault or afixed[attribute],then aValue Constraint as follows, otherwise·absent·.

Property

Value

eitherdefault orfixed, as appropriate

the·actual value· (with respect to the{type definition}) of the[attribute]

the·normalized value· (with respect to the{type definition}) of the[attribute]

The·actual value· of theinheritable[attribute], if present, otherwisefalse.

The·annotation mapping· of the<attribute> element, as defined inXML Representation of Annotation Schema Components (§3.15.2).

3.2.2.2 Mapping Rules for Local Attribute Declarations

If the<attribute> element information item has<complexType> or<attributeGroup> as an ancestor and theref[attribute] is absent, it maps both to an attribute declaration (seebelow) and to an attribute use with properties as follows (unlessuse='prohibited', in which case the item corresponds to nothing at all):

XML Mapping Summary forAttribute UseSchema Component

Property

Representation

{required}

true if the<attribute> element hasuse =required, otherwisefalse.

{attribute declaration}

See the Attribute Declaration mappingimmediately below.

If there is adefault or afixed[attribute],then aValue Constraint as follows, otherwise·absent·.

Property

Value

eitherdefault orfixed, as appropriate

the·actual value· of the[attribute] (with respect to{attribute declaration}.{type definition})

the·normalized value· of the[attribute] (with respect to{attribute declaration}.{type definition})

The·actual value· of theinheritable[attribute], if present, otherwisefalse.

The same annotations as the{annotations} ofthe Attribute Declaration. See below.

The<attribute> element also maps to the{attribute declaration} of the attribute use, as follows:

XML Mapping Summary forAttribute DeclarationSchema Component

Property

Representation

The·actual value· of thename[attribute]

The appropriatecase among the following:

1IftargetNamespace is present ,then its·actual value·.

2IftargetNamespace is not present andone of the following is true

2.1form =qualified

2.2form is absent and the<schema> ancestor hasattributeFormDefault =qualified

then the·actual value· of thetargetNamespace[attribute] of the ancestor<schema> element information item, or·absent· if there is none.

3otherwise·absent·.

AScope as follows:

Property

Value

local

{parent}

If the<attribute> element information item has<complexType> as an ancestor, theComplex Type Definition corresponding to that item, otherwise (the<attribute> element information item is within an<attributeGroup> element information item), theAttribute Group Definition corresponding to that item.

·absent·.

The·actual value· of theinheritable[attribute], if present, otherwisefalse.

The·annotation mapping· of the<attribute> element, as defined inXML Representation of Annotation Schema Components (§3.15.2).

3.2.2.3 Mapping Rules for References to Top-level Attribute Declarations

If the<attribute> element information item has<complexType> or<attributeGroup> as an ancestor and theref[attribute] is present, it maps to an attribute use with properties as follows (unlessuse='prohibited', in which case the item corresponds to nothing at all):

XML Mapping Summary forAttribute UseSchema Component

Property

Representation

{required}

true ifuse =required, otherwisefalse.

{attribute declaration}

The (top-level)attribute declaration·resolved· to by the·actual value· oftheref[attribute]

If there is adefault or afixed[attribute],then aValue Constraint as follows, otherwise·absent·.

Property

Value

eitherdefault orfixed, as appropriate

the·actual value· of the[attribute] (with respect to{attribute declaration}.{type definition})

the·normalized value· of the[attribute] (with respect to{attribute declaration}.{type definition})

The·actual value· of theinheritable[attribute], if present, otherwise{attribute declaration}.{inheritable}.

Attribute Declaration for the 'type' attribute

The·annotation mapping· of the<attribute> element, as defined inXML Representation of Annotation Schema Components (§3.15.2).

3.2.3 Constraints on XML Representations of Attribute Declarations

Schema Representation Constraint: Attribute Declaration Representation OK

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

1default andfixedmust not both be present.

2Ifdefault anduse are both present,usemust have the·actual value·optional.

3 If the item's parent is not<schema>, thenall of the followingmust be true:

3.1One ofref orname is present, but not both.

3.2Ifref is present, then all of<simpleType>,form andtype are absent.

4Thetype attribute and a<simpleType> child elementmust not both be present.

5 Iffixed anduse are both present,usemust not have the·actual value·prohibited.

6 If thetargetNamespace attribute is present thenall of the followingmust be true:

6.1Thename attribute is present.

6.2Theform attribute is absent.

6.3 If the ancestor<schema> does not have atargetNamespace[attribute] or its·actual value· is different from the·actual value· oftargetNamespace of<attribute>, thenall of the following are true:

6.3.1<attribute> has<complexType> as an ancestor

6.3.2There is a<restriction> ancestorbetween the<attribute> and the nearest<complexType> ancestor, and the·actual value· of thebase[attribute] of<restriction> does not·match· thename of·xs:anyType·.

3.2.4 Attribute Declaration Validation Rules

3.2.4.1 Attribute Locally Valid

Informally, an attribute in an XML instance is locally·valid· against an attribute declaration if and only if (a) the name of the attribute matches the name of the declaration, (b) after whitespace normalization its·normalized value· is locally valid against the type declared for the attribute, and (c) the attribute obeys any relevant value constraint. Additionally, forxsi:type, it is required that the type named by the attribute be present in the schema. A logical prerequisite for checking the local validity of an attribute against an attribute declaration is that the attribute declaration itself and the type definition it identifies both be present in the schema.

Local validity of attributes is tested as part of schema-validity·assessment· of attributes (and of the elements on which they occur), and the result of the test is exposed in the[validity] property of the·post-schema-validation infoset·.

A more formal statement is given in the following constraint.

Validation Rule: Attribute Locally Valid

For an attribute information itemAto be locally·valid· with respect to an attribute declarationDall of the followingmust be true:

1D is not·absent· (seeMissing Sub-components (§5.3) for how this can fail to be the case) andD andA have the sameexpanded name.

2D.{type definition} is not·absent·.

3A's·initial value· is locally·valid· with respect toD.{type definition} as perString Valid (§3.16.4).

4IfD.{value constraint} is present andD.{value constraint}.{variety} =fixed, thenA's·actual value· is equal or identical toD.{value constraint}.{value}.

5 IfD is the built-in declaration forxsi:type (Attribute Declaration for the 'type' attribute (§3.2.7.1)), thenA's·actual value··resolves· to a type definition.

3.2.4.2 Governing Attribute Declaration and Governing Type Definition

[Definition:] In a given schema-validity·assessment· episode, the·governing· declaration of an attribute (itsgoverning attribute declaration) is the first of the following which applies:

1A declaration which was stipulated by the processor (seeAssessing Schema-Validity (§5.2)).

2Its·context-determined declaration·;

3A declaration·resolved· to by its[local name] and[namespace name], provided the attribute is not·skipped· and the processor has not stipulated a type definition at the start of·assessment·.

If none of these applies, the attribute has no·governing attribute declaration· (or, in equivalent words, the·governing attribute declaration· is·absent·).

Note: As a consequence, unless·skipped· or stipulated otherwise, attributes namedxsi:type,xsi:nil,xsi:schemaLocation, orxsi:noNamespaceSchemaLocation are always governed by their corresponding built-in declarations (seeBuilt-in Attribute Declarations (§3.2.7)).

[Definition:] Thegoverning type definition of an attribute, in a given schema-validity·assessment· episode, is the first of the following which applies:

1A type definition stipulated by the processor (seeAssessing Schema-Validity (§5.2)).

2The{type definition} of the·governing attribute declaration·.

If neither of these applies, there is no·governing type definition· (or, in equivalent words, it is·absent·).

3.2.4.3 Schema-Validity Assessment (Attribute)

Schema-validity assessment of an attribute information item involves identifying its·governing attribute declaration· and checking its local validity against the declaration. If the·governing type definition· is not present in the schema, then assessment is necessarily incomplete.

Validation Rule: Schema-Validity Assessment (Attribute)

The schema-validity assessment of an attribute information item depends on its local·validation· alone.

For an attribute information item's schema-validity to have been assessedall of the followingmust be true:

1A·non-absent· attribute declaration is known for it, namely its·governing· declaration.

2Its local·validity· with respect to that declaration has been evaluated as perAttribute Locally Valid (§3.2.4.1).

3Both clause1 and clause2 ofAttribute Locally Valid (§3.2.4.1) are satisfied.

[Definition:] Forattribute information items, there is no difference between assessment and strictassessment, so the attribute information item hasbeenstrictly assessedif and only if its schema-validity has been assessed.

3.2.5 Attribute Declaration Information Set Contributions

3.2.5.1 Assessment Outcome (Attribute)

Schema Information Set Contribution: Assessment Outcome (Attribute)

If the schema-validity of an attribute information item has been assessed as perSchema-Validity Assessment (Attribute) (§3.2.4.3), then in the·post-schema-validation infoset· it has properties as follows:

PSVI Contributions for attribute information items

[validation context]: The nearest ancestor element information item with a[schema information] property.
[validity]: The appropriatecase among the following:
1Ifit was·strictly assessed·,then the appropriatecase among the following:
1.1Ifit was locally·valid· as defined byAttribute Locally Valid (§3.2.4.1),thenvalid;
1.2otherwiseinvalid.
2otherwisenotKnown.
[validation attempted]: The appropriatecase among the following:
1Ifit was·strictly assessed·,thenfull;
2otherwisenone.
[schema specified]: infoset. SeeAttribute Default Value (§3.4.5.1) for the other possible value.

3.2.5.2 Validation Failure (Attribute)

Schema Information Set Contribution: Validation Failure (Attribute)

If and only if the local·validity·, as defined byAttribute Locally Valid (§3.2.4.1)above, of an attribute information item has been assessed,then in the·post-schema-validation infoset· the item has a property:

PSVI Contributions for attribute information items

[schema error code]: The appropriatecase among the following:
1Ifthe item is·invalid·,thena list. Applications wishing to provideinformation as to the reason(s) for the·validation· failure are encouraged to record one or moreerror codes (seeOutcome Tabulations (normative) (§B)) herein.
2otherwise·absent·.

3.2.5.3 Attribute Declaration

Schema Information Set Contribution: Attribute Declaration

If and only if a·governing·declaration is known for an attribute information item then in the·post-schema-validation infoset· the attribute information itemhas aproperty:

PSVI Contributions for attribute information items

[attribute declaration]: An·item isomorphic· to the·governing· declaration component itself.
[schema default]: If the attribute information item is·attributed· to anAttribute Use then the{lexical form} of the·effective value constraint·, otherwise the{lexical form} of the declaration's{value constraint}.

3.2.5.4 Attribute Validated by Type

Schema Information Set Contribution: Attribute Validated by Type

If andonly if a·governing type definition· is known foran attribute informationitem, then in the·post-schema-validation infoset· theattribute information itemhas theproperties:

PSVI Contributions for attribute information items

[schema normalized value]: If the attribute's·normalized value· is·valid· with respect to the·governing type definition·,then the·normalized value· as·validated·, 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· tothe·governing type definition·component.
[type definition type]: simple.
[type definition namespace]: The{target namespace} of the·typedefinition·.
[type definition anonymous]: trueif the{name} of the·typedefinition· is·absent·,otherwisefalse.
[type definition name]: The{name} of the·type definition·, if the{name} is not·absent·. If the·type definition·'s{name} property is·absent·, thenschema processorsmay, but neednot, provide a valuewhich uniquely identifies thistype definition among those with the same target namespace.It is·implementation-defined· whether a processor provides a namefor such a type definition. If a processor does provide a value in thissituation, the choice of what value to use is·implementation-dependent·.

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

If the attribute's·initial value· is·valid· with respect to the·governing type definition·as defined byString Valid (§3.16.4) andthe·governing type definition· has{variety}union, then there are four additional properties:

PSVI Contributions for attribute information items

[member type definition]: an·item isomorphic· to the·validating type· of the[schema actual value].
[member type definition namespace]: The{target namespace} of the·validating type·.
[member type definition anonymous]: true if the{name} of the·validating type· is·absent·,otherwisefalse.
[member type definition name]: The{name} of the·validating type·, if it is not·absent·. If it is·absent·, schema processorsmay, but neednot, provide a value unique to the definition.It is·implementation-defined· whether a processor provides a namefor such a type definition. If a processor does provide a value in thissituation, the choice of what value to use is·implementation-dependent·.

The first (·item isomorphic·)alternative above is provided for applications such as queryprocessors which need access to the full range of details about anitem's·assessment·, for example thetype hierarchy; the second, for lighter-weight processors for whomrepresenting the significant parts of the type hierarchy asinformation items might be a significant burden.

Ifall of the following are true:

1 the attribute's·normalized value· is·valid· with respect to the·governing type definition·;

2One of the following is true:

2.1 the·governing type definition· has{variety} =list;

2.2 the·governing type definition· has{variety} =union and the·validating type· of the[schema actual value] has{variety} =list;

3 the{item type definition} of the list type (from the previous clause) has{variety} =union;

then there is an additional property:

PSVI Contributions for attribute information items

[member type definitions]: a sequence ofSimple Type Definition components, with the same length as the[schema actual value], each one an·item isomorphic· to the·validating type· of the corresponding item in the[schema actual value].

See alsoAttribute Default Value (§3.4.5.1),Match Information (§3.4.5.2) andSchema Information (§3.17.5.1), which describeother information set contributions related to attribute information items.

3.2.6 Constraints on Attribute Declaration Schema Components

All attribute declarations (seeAttribute Declarations (§3.2))must satisfy the following constraints.

3.2.6.1 Attribute Declaration Properties Correct

Schema Component Constraint: Attribute Declaration Properties Correct

All of the followingmust be true:

1The values of the properties of an attribute declaration are as described in the property tableau inThe Attribute Declaration Schema Component (§3.2.1), modulo the impact ofMissing Sub-components (§5.3).

2if there is a{value constraint}, then it is a valid default with respect to the{type definition} as defined inSimple Default Valid (§3.2.6.2).

Note: The use ofID and relatedtypes together with value constraints goes beyond what is possible with XML DTDs, andshould be avoided if compatibility with DTDs is desired.

3.2.6.2 Simple Default Valid

Schema Component Constraint: Simple Default Valid

For a Value ConstraintVto bea valid default with respect to aSimple Type DefinitionTall of the followingmust be true:

1V.{lexical form} is·valid· with respect toT as defined byDatatype Valid in[XML Schema: Datatypes].

2V.{lexical form} maps toV.{value} in the value space ofT.

3.2.6.3`xmlns` Not Allowed

Schema Component Constraint:xmlns Not Allowed

The{name} of an attribute declarationmust not matchxmlns.

Note: The{name} of an attribute is an·NCName·, which implicitly prohibits attribute declarations of the formxmlns:*.

3.2.6.4`xsi:` Not Allowed

Schema Component Constraint:xsi: Not Allowed

The{target namespace} of an attribute declaration,whether local or top-level,must not matchhttp://www.w3.org/2001/XMLSchema-instance(unless it is one of the four built-in declarations given in the next section).

Note: This reinforces the special status of these attributes, so that they not onlyneed not be declared to be allowed in instances, but in consequence of the rule just givenmust not be declared.

Note: It is legal forAttribute Uses that refer toxsi: attributes to specify default or fixed value constraints (e.g. in a component corresponding to a schema document construct of the form<xs:attribute ref="xsi:type" default="xs:integer"/>), but the practice is not recommended; including such attribute uses will tend to mislead readers of the schema document, because the attribute uses would have no effect; seeElement Locally Valid (Complex Type) (§3.4.4.2) andAttribute Default Value (§3.4.5.1) for details.

3.2.7 Built-in Attribute Declarations

There are four attribute declarations present in everyschema by definition:

3.2.7.1`xsi:type`

Thexsi:type attribute is used to signal use of a type other than the declared type of an element. Seexsi:type (§2.7.1).

Property

Value

type

http://www.w3.org/2001/XMLSchema-instance

The built-inQName simpletype definition

AScope as follows:

Property

Value

global

Attribute Declaration for the 'nil' attribute

3.2.7.2`xsi:nil`

Thexsi:nil attribute is used to signal that an element's content is "nil" (or "null"). Seexsi:nil (§2.7.2).

Property

Value

nil

http://www.w3.org/2001/XMLSchema-instance

The built-inboolean simpletype definition

AScope as follows:

Property

Value

global

Attribute Declaration for the 'schemaLocation' attribute

3.2.7.3`xsi:schemaLocation`

Thexsi:schemaLocation attribute is used to signal possible locations of relevant schema documents. Seexsi:schemaLocation, xsi:noNamespaceSchemaLocation (§2.7.3).

Property

Value

schemaLocation

http://www.w3.org/2001/XMLSchema-instance

An anonymous simple type definition, as follows:

Property

Value

http://www.w3.org/2001/XMLSchema-instance

The built in·xs:anySimpleType·

list

The built-inanyURI simpletype definition

AScope as follows:

Property

Value

global

Attribute Declaration for the 'noNamespaceSchemaLocation' attribute

3.2.7.4`xsi:noNamespaceSchemaLocation`

Thexsi:noNamespaceSchemaLocation attribute is used to signal possible locations of relevant schema documents. Seexsi:schemaLocation, xsi:noNamespaceSchemaLocation (§2.7.3).

Property

Value

noNamespaceSchemaLocation

http://www.w3.org/2001/XMLSchema-instance

The built-inanyURI simpletype definition

AScope as follows:

Property

Value

global

3.3 Element Declarations

        3.3.1The Element Declaration Schema Component
        3.3.2XML Representation of Element Declaration Schema Components
            3.3.2.1Common Mapping Rules for Element Declarations
            3.3.2.2Mapping Rules for Top-Level Element Declarations
            3.3.2.3Mapping Rules for Local Element Declarations
            3.3.2.4References to Top-Level Element Declarations
            3.3.2.5Examples of Element Declarations
        3.3.3Constraints on XML Representations of Element Declarations
        3.3.4Element Declaration Validation Rules
            3.3.4.1Selected and Instance-specified Type Definitions
            3.3.4.2Type Override and Valid Substitutability
            3.3.4.3Element Locally Valid (Element)
            3.3.4.4Element Locally Valid (Type)
            3.3.4.5Validation Root Valid (ID/IDREF)
            3.3.4.6Schema-Validity Assessment (Element)
        3.3.5Element Declaration Information Set Contributions
            3.3.5.1Assessment Outcome (Element)
            3.3.5.2Validation Failure (Element)
            3.3.5.3Element Declaration
            3.3.5.4Element Validated by Type
            3.3.5.5Element Default Value
            3.3.5.6Inherited Attributes
        3.3.6Constraints on Element Declaration Schema Components
            3.3.6.1Element Declaration Properties Correct
            3.3.6.2Element Default Valid (Immediate)
            3.3.6.3Substitution Group OK (Transitive)
            3.3.6.4Substitution Group

Element declarations provide for:

Local·validation· of element information item values using a type definition;
Specifying default or fixed values for element information items;
Establishing uniquenesses and reference constraint relationships among the values of related elements andattributes;
Controlling the substitutability of elements through themechanism of·element substitution groups·.

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

3.3.1 The Element Declaration Schema Component

The element declaration schema component has the following properties:

Schema Component:, a kind ofTerm

{annotations}

A sequence ofAnnotation components.

{name}

An xs:NCName value. Required.

{target namespace}

An xs:anyURI value. Optional.

{type definition}

AType Definition component. Required.

{type table}

AType Table property record. Optional.

{scope}

AScope property record. Required.

{value constraint}

AValue Constraint property record. Optional.

{nillable}

An xs:boolean value. Required.

{identity-constraint definitions}

A set ofIdentity-Constraint Definition components.

{substitution group affiliations}

A set ofElement Declaration components.

{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 ofType Alternative components.

{default type definition}

AType Alternative component. Required.

Property Record:Scope

{variety}

One of {global,local}. Required.

{parent}

Either aComplex Type Definition or aModel Group Definition. Required if{variety} islocal, otherwisemust be·absent·

Property Record:Value Constraint

{variety}

One of {default,fixed}. Required.

{value}

An·actual value·. Required.

{lexical form}

A character string. Required.

The{name} propertymust match the local part of the names of element information items being·validated·.

For an element declarationE, ifE.{scope}.{variety} =global, thenE is available for use throughout the schema. IfE.{scope}.{variety} =local, thenE is available for use only within (theComplex Type Definition orModel Group Definition)E.{scope}.{parent}.

A·non-absent· value of the{target namespace} property provides for·validation· of namespace-qualified element information items.·Absent· values of{target namespace}·validate· unqualified items.

An element information item is normally required to satisfy the{type definition}. For such an item, schema information set contributions appropriate to the{type definition} are added to the corresponding element information item in the·post-schema-validation infoset·. The type definition against which an element information item is validated (its·governing type definition·) can be different from the declared{type definition}. The{type table} property of anElement Declaration, which governs conditional type assignment, andthexsi:type attribute of an element information item (seexsi:type (§2.7.1)) can cause the·governing type definition· and thedeclared{type definition} to be different.

If{nillable} istrue, then an element with no text or element content can be·valid· despite a{type definition} which would otherwise require content, if it carries the attributexsi:nil with the valuetrue (seexsi:nil (§2.7.2)). Formal details of element·validation· are described inElement Locally Valid (Element) (§3.3.4.3).

[Definition:] An element information itemE isnilled with respect to some element declarationD if and only ifall of the following are true:

1E hasxsi:nil =true.

2D.{nillable} =true.

IfE is said to be·nilled· without the identity ofD being clear from the context, thenD is assumed to beE's·governing element declaration·.

{value constraint} establishes a default or fixed value for an element. If a{value constraint} with{variety} =default is present, and if the element being·validated· is empty, then forpurposes of calculating the[schema normalized value]and other contributions to the·post-schema-validation infoset· the element is treated as if{value constraint}.{lexical form} was used as the content of the element. Iffixed is specified, then the element's contentmust either be empty, in which casefixed behaves asdefault, or its valuemust be equal or identical to{value constraint}.{value}.

Note: When a default value is supplied and used, as described in the second sentence of the preceding paragraph, the default value is used to calculate the[schema normalized value], etc., but the actual content of the element is not changed: the element contained no character information items in the input information set, and it contains none in the PSVI.

Note: The provision of defaults for elements goes beyond what is possible in XML DTDs, and does not exactly correspond to defaults for attributes. Inparticular, an element with a non-empty{value constraint} whose simple type definition includes the empty string in its lexical space will nonetheless never receive thatvalue, because the{value constraint} will override it.

{identity-constraint definitions} express constraints establishing uniquenesses and reference relationships among the values of related elements and attributes. SeeIdentity-constraint Definitions (§3.11).

The{substitution group affiliations} property of an element declaration indicates which·substitution groups·, if any, it can potentially be a member of. Potential membership is transitive but not symmetric; an element declaration is a potential member of any group named in its{substitution group affiliations}, and also of any group of which any entry in its{substitution group affiliations} is a potential member. Actual membershipmay be blocked by the effects of{substitution group exclusions} or{disallowed substitutions}, see below.

An empty{substitution group exclusions} allows a declaration to be named in the{substitution group affiliations} of other element declarations having the same declared{type definition} or some type·derived· therefrom. The explicit values of{substitution group exclusions},extension orrestriction, rule out element declarations having types whose derivation from{type definition} involves anyextension steps, orrestriction steps, respectively.

The supplied values for{disallowed substitutions} determine whether an element declaration appearing in a·content model· will be prevented from additionally·validating· elements (a) with anxsi:type (§2.7.1) that identifies anextension orrestriction of the type of the declared element, and/or (b) from·validating· elements which are in the·substitution group· headed by the declared element. If{disallowed substitutions} is empty, then all·derived· types and·substitution group· members are allowed.

Element declarations for which{abstract} istrue can appear in content models only when substitution is allowed; such declarationsmust not themselves ever be used to·validate· element content.

SeeAnnotations (§3.15) for information on the role of the{annotations} property.

3.3.2 XML Representation of Element Declaration Schema Components

The XML representation for an element declaration schema component is an<element> element information item. It specifies a type definition for an element either by reference or explicitly, andmay provide occurrence and default information. The correspondences between the properties of the information item after the appropriate·pre-processing· and the properties of the component(s) it corresponds to are given in this section.

XML Representation Summary:element Element Information Item

<element
 abstract =boolean : false
 block = (#all | List of (extension |restriction |substitution))
 default =string
 final = (#all | List of (extension |restriction))
 fixed =string
 form = (qualified |unqualified)
 id =ID
 maxOccurs = (nonNegativeInteger |unbounded) : 1
 minOccurs =nonNegativeInteger : 1
 name =NCName
 nillable =boolean : false
 ref =QName
 substitutionGroup = List ofQName
 targetNamespace =anyURI
 type =QName
 {any attributes with non-schema namespace . . .}>
 Content:(annotation?, ((simpleType |complexType)?,alternative*, (unique |key |keyref)*))
</element>

An<element> elementinformation item in a schema document maps to an element declaration and allows thetype definition of that declaration to be specified either byreference or by explicit inclusion.

Top-level<element>elements (i.e. those which appear withinthe schema document as children of<schema> elements) produceglobal element declarations;<element>s within<group> or<complexType> produce either particles which containglobal element declarations (if there's aref attribute) or local declarations (otherwise). For complete declarations, top-level or local, thetype attribute is used when the declaration can use abuilt-in or user-defined global type definition. Otherwise ananonymous<simpleType> or<complexType> is provided inline.

Element information items·validated· by a top-level declarationmust be qualified with the{target namespace} of that declaration.If the{target namespace} is·absent·,the itemmust be unqualified.Control over whether element information items·validated· by a local declarationmust be similarly qualified or notis provided by theform[attribute], whose default is providedby theelementFormDefault[attribute] on the enclosing<schema>, via its determination of{target namespace}.

The names for top-level element declarations are in a separate·symbol space· from the symbol spaces forthe names of type definitions, so there can (but neednot be) a simple or complex type definition with the same name as atop-level element. The names of locally-scopedelement declarations need not be unique and thus reside in no symbol space at all (but the element declarations areconstrained byElement Declarations Consistent (§3.8.6.3)).

Note that the above allows for two levels of defaulting for unspecifiedtype definitions. An<element> with no referenced or included type definition willcorrespond to an element declaration which hasthe same type definition as the first substitution-group head named in thesubstitutionGroup[attribute], if present,otherwise·xs:anyType·. This has the important consequence that the minimum valid element declaration, that is, one with only aname attribute and no contents, is also (nearly) the most general, validating any combination of text and element content and allowing any attributes, and providing for recursive validation where possible.

SeeXML Representation of Identity-constraint Definition Schema Components (§3.11.2) for<key>,<unique> and<keyref>.

The following sections specify several sets of XML mapping rules which apply in different circumstances.

If the<element> element information item has<schema> as its parent, it maps to anElement Declaration using the mappings described inCommon Mapping Rules for Element Declarations (§3.3.2.1) andMapping Rules for Top-Level Element Declarations (§3.3.2.2).
If the<element> element information item has<complexType> or<group> as an ancestor, and theref[attribute] is absent, and it does not haveminOccurs=maxOccurs=0, then it maps both to aParticle, as described inMapping Rules for Local Element Declarations (§3.3.2.3), and also to anElement Declaration, using the mappings described inCommon Mapping Rules for Element Declarations (§3.3.2.1) andMapping Rules for Local Element Declarations (§3.3.2.3).
If the<element> element information item has<complexType> or<group> as an ancestor, and theref[attribute] is present, and it does not haveminOccurs=maxOccurs=0, then it maps to aParticle as described inReferences to Top-Level Element Declarations (§3.3.2.4).
If the<element> element information item hasminOccurs=maxOccurs=0, then it maps to no component at all.
Note: TheminOccurs andmaxOccurs attributes are not allowed on top-level<element> elements, so in valid schema documents this will happen only when the<element> element information item has<complexType> or<group> as an ancestor.

3.3.2.1 Common Mapping Rules for Element Declarations

The following mapping rules apply in all cases where an<element> element maps to anElement Declaration component.

XML Mapping Summary forElement DeclarationSchema Component

Property

Representation

The·actual value· of thename[attribute].

{default type definition}

The first of the following that applies:

1The type definition corresponding to the<simpleType> or<complexType> element information item in the[children], if either is present.

2 The type definition·resolved· to by the·actual value· of thetype[attribute], if it is present.

3The declared{type definition} of theElement Declaration ·resolved· to by the firstQName in the·actual value· of thesubstitutionGroup[attribute], if present.

4·xs:anyType·.

{type table}

AType Table corresponding to the<alternative> elementinformationitems among the[children], if any, as follows, otherwise·absent·.

Property

Value

{alternatives}

A sequence ofType Alternatives, each corresponding, in order, to one of the<alternative> elements which have atest[attribute].

Depends upon the final<alternative> element among the[children]. If it has notest[attribute], the final<alternative> maps to the{default type definition}; if it does have atest attribute, it is covered by the rule for{alternatives} and the{default type definition} is taken from the declared type of theElement Declaration. So the value of the{default type definition} is given by the appropriatecase among the following:

1Ifthe<alternative> has notest[attribute],thenaType Alternative corresponding to the<alternative>.

2otherwise(the<alternative> has atest) aType Alternative with the following properties:

Property

Value

{test}

·absent·.

the{type definition} property of the parentElement Declaration.

the empty sequence.

{nillable}

The·actual value· of thenillable[attribute], if present, otherwisefalse.

If there is adefault or afixed[attribute], then aValue Constraint as follows, otherwise·absent·.[Definition:] Use the nameeffective simple type definition for the declared{type definition}, if it is a simple type definition, or, if{type definition}.{content type}.{variety} =simple, for{type definition}.{content type}.{simple type definition}, or else for the built-instring simple type definition).

Property

Value

eitherdefault orfixed, as appropriate

the·actual value· (with respect to the·effective simple type definition·) of the[attribute]

{identity- constraint definitions}

the·normalized value· (with respect to the·effective simple type definition·) of the[attribute]

A setconsisting of the identity-constraint-definitions corresponding toall the<key>,<unique> and<keyref> elementinformation items in the[children], if any, otherwise theempty set.

{substitution group affiliations}

A set of the element declarations·resolved· to by the items in the·actual value· of thesubstitutionGroup[attribute], if present,otherwise the empty set.

{disallowed substitutions}

A setdepending on the·actual value· of theblock[attribute], if present, otherwise on the·actual value· of theblockDefault[attribute] of the ancestor<schema> element information item, if present,otherwise on the empty string. Call this theEBV (for effective block value). Then thevalue of this property isthe appropriatecase among the following:

1IftheEBV is the empty string,thenthe empty set;

2IftheEBV is#all,then{extension,restriction,substitution};

3otherwisea set with members drawn from the set above, each being present or absent depending on whether the·actual value· (which is a list) contains an equivalently named item.

Note: Although theblockDefault[attribute] of<schema>may include values other thanextension,restriction orsubstitution, those values are ignored in the determination of{disallowed substitutions} for element declarations (theyare used elsewhere).

{substitution group exclusions}

As for{disallowed substitutions} above,but using thefinal andfinalDefault[attributes] in place of theblock andblockDefault[attributes] and with the relevantset being{extension,restriction}.

{abstract}

The·actual value· of theabstract[attribute], if present, otherwisefalse.

The·annotation mapping· of the<element> element and any of its<unique>,<key> and<keyref>[children] with aref[attribute], as defined inXML Representation of Annotation Schema Components (§3.15.2).

3.3.2.2 Mapping Rules for Top-Level Element Declarations

If the<element> element information item has<schema> as its parent, itmaps to aglobalElement Declaration, using the mapping giveninCommon Mapping Rules for Element Declarations (§3.3.2.1),supplemented by the following.

XML Mapping Summary forElement DeclarationSchema Component

Property

Representation

The·actual value· of thetargetNamespace[attribute] of the parent<schema> element information item, or·absent· if there is none.

AScope as follows

Property

Value

global

{parent}

3.3.2.3 Mapping Rules for Local Element Declarations

If the<element> element information item has<complexType> or<group> as an ancestor, and theref[attribute] is absent, and it does not haveminOccurs=maxOccurs=0, then it maps both to aParticle and to a localElement Declaration which is the{term}of thatParticle. TheParticleis as follows:

XML Mapping Summary forParticleSchema Component

Property

Representation

The·actual value· of theminOccurs[attribute], if present, otherwise1.

unbounded, if themaxOccurs[attribute] equalsunbounded, otherwise the·actual value· of themaxOccurs[attribute], if present, otherwise1.

A (local) element declaration asgiven below.

The same annotations as the{annotations} of the{term}.

The<element> element also maps to an element declaration using themapping rules given inCommon Mapping Rules for Element Declarations (§3.3.2.1), supplemented by thosebelow:

XML Mapping Summary forElement DeclarationSchema Component

Property

Representation

The appropriatecase among the following:

1IftargetNamespace is present ,then its·actual value·.

2IftargetNamespace is not present andone of the following is true

2.1form =qualified

2.2form is absent and the<schema> ancestor haselementFormDefault =qualified

then the·actual value· of thetargetNamespace[attribute] of the ancestor<schema> element information item, or·absent· if there is none.

3otherwise·absent·.

AScope as follows:

Property

Value

local

{parent}

If the<element> element information item has<complexType> as an ancestor, theComplex Type Definition corresponding to that item, otherwise (the<element> element information item is within a named<group> element information item), theModel Group Definition corresponding to that item.

3.3.2.4 References to Top-Level Element Declarations

If the<element> element information item has<complexType> or<group> as an ancestor, and theref[attribute] is present, and it does not haveminOccurs=maxOccurs=0, then it maps toaParticle as follows.

XML Mapping Summary forParticleSchema Component

Property

Representation

The·actual value· of theminOccurs[attribute], if present, otherwise1.

unbounded, if themaxOccurs[attribute] equalsunbounded, otherwise the·actual value· of themaxOccurs[attribute], if present, otherwise1.

The (top-level) elementdeclaration·resolved· to by the·actual value· of theref[attribute].

8An·instance-specified type definition·.

The·annotation mapping· of the<element> element, as defined inXML Representation of Annotation Schema Components (§3.15.2).

3.3.2.5 Examples of Element Declarations

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 second uses an embedded anonymous complextype definition.

The last two examples illustrate the use of local element declarations. Instances ofmyLocalElement withincontextOne will be constrained bymyFirstType,while those withincontextTwo will be constrained bymySecondType.

Note: The possibility that differing attribute declarations and/or content modelswould apply to elements with the same name in different contexts is anextension beyond the expressive power of a DTD in XML.

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. Thefacet type is definedand thefacet element is declared to use it. Thefacet element is abstract -- it'sonly defined to stand as the head for a·substitution group·. Two furtherelements are declared, each a member of thefacet·substitution group·. Finally a type is defined which refers tofacet, therebyallowingeitherperiod orencoding (orany other member of the group).

Example

The following example illustrates conditional type assignmentto an element, based on the value of one of the element's attributes.Each instance of themessage element will beassigned either to typemessageType or to a morespecific type derived from it.

The typemessageType accepts any well-formed XMLor character sequence as content, and carries akindattribute which can be used to describe the kind or format of the message. The value ofkind is either one of a few well known keywords or, failing that, any string.

<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 ofmessageType are defined, eachcorresponding to one of the three well-known formats:messageTypeString forkind="string",messageTypeBase64 forkind="base64" andkind="binary", andmessageTypeXML forkind="xml" orkind="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>

Themessage element itself usesmessageType both as its declared type andas its default type, and usestest attributes on its<alternative>[children] to assign the appropriatespecialized message type to messages with the well knownvalues for thekind attribute.Because the declared type and the default type are the same, the last<alternative> (without thetest attribute)can be omitted.

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

3.3.3 Constraints on XML Representations of Element Declarations

Schema Representation Constraint: Element Declaration Representation OK

In addition to the conditions imposed on<element> elementinformation items by the schema for schema documents:all of the followingmust be true:

1default andfixed are notboth present.

2 If the item's parent is not<schema>, thenall of the following are true:

2.1One ofref orname is present, but not both.

2.2Ifref is present, thenno unqualified attributes are present other thanminOccurs,maxOccurs, andid, and no children in the Schema namespace (xs) other than<annotation>.

3The<element> element does not have both a<simpleType> or<complexType> child and atype attribute.

4 IftargetNamespace is present thenall of the following are true:

4.1name is present.

4.2form is not present.

4.3 If the ancestor<schema> does not have atargetNamespace[attribute] or its·actual value· is different from the·actual value· oftargetNamespace of<element>, thenall of the following are true:

4.3.1<element> has<complexType> as an ancestor

4.3.2There is a<restriction> ancestorbetween the<element> and the nearest<complexType> ancestor, and the·actual value· of thebase[attribute] of<restriction> does not·match· thename of·xs:anyType·.

5Every<alternative> element butthe last has atest[attribute]; the last<alternative> elementmay have such an[attribute].

3.3.4 Element Declaration Validation Rules

When an element is·assessed·, it is first checked against its·governing element declaration·, if any; this in turn entails checking it against its·governing type definition·. The second step is recursive: the element's[attributes] and[children] are·assessed· in turn with respect to the declarations assigned to them by their parent's·governing type definition·.

3.3.4.1 Selected and Instance-specified Type Definitions

The·governing type definition· of an element is normally the declared{type definition} associated with the·governing element declaration·, but this may be·overridden· using conditional type assignment in theElement Declaration or using an·instance-specified type definition·, or both. When the element is declared withconditional type assignment, the·selected type definition· is used as the·governing type definition· unless·overridden· by an·instance-specified type definition·.

[Definition:] Theselected type definitionS of an element information itemE is atype definition associated withE in the following way. LetD be the·governing element declaration· ofE. Then:

1 IfD has a{type table}, thenS is the type·conditionally selected· forE byD.{type table}.

2IfD has no{type table}, thenS isD.{type definition}.

IfE has no·governing element declaration·, thenE has no selectedtype definition.

Note: It is a consequence ofElement Declaration Properties Correct (§3.3.6.1) that ifD is valid, thenS will be·validly substitutable· forD's declared{type definition}, or else thatS will be·xs:error·.

[Definition:] Given aType TableT and an elementinformation itemE,Tconditionally selects atypeS forE in the following way. The{test} expressions inT's{alternatives} are evaluated, in order, until one of theType Alternatives·successfully selects· a type definition forE, or until all have been tried without success. If anyType Alternative ·successfully selects· a type definition, none of the followingType Alternatives are tried. Then the typeSconditionally selected forE byT isas described in the appropriatecase among the following:

1 If at least oneType Alternative inT.{alternatives}·successfully selects· a type definition forE, thenS is the type definition selected by the first suchType Alternative.

2 If noType Alternative inT.{alternatives}·successfully selects· a type definition, thenS isT.{default type definition}.{type definition}.

[Definition:] Aninstance-specified type definition is a type definition associated with an element information item in the following way:

1Among the element's attribute information items is one namedxsi:type.

2The·normalized value· of that attribute information item is a qualified name·valid· with respect to the built-inQName simple type, as defined byString Valid (§3.16.4).

3The·actual value· (a·QName·)·resolves· to a type definition. It is this type definition which is theinstance-specified type definition.

3.3.4.2 Type Override and Valid Substitutability

[Definition:] An·instance-specified type definition·S is said tooverride another type definitionT if and only if all of the following are true:

1S is the·instance-specified type definition· on some element information itemE. A·governing element declaration· may or may not be known forE.

2S is·validly substitutable· forT, subject to the blocking keywords of the{disallowed substitutions} ofE's·governing element declaration·, if any, or·validly substitutable without limitation· forT (if no·governing element declaration· is known).

Note: Typically,T would be the·governing type definition· forE if it were not overridden. (This will be the case ifT was stipulated by the processor, as described inAssessing Schema-Validity (§5.2), orE has a·governing element declaration· andT is its declared type, orT is the·locally declared type· ofE.)

Note: The use of the term "·override·"to denote the relation between an·instance-specified type definition·S and another typeT has nothing to do with the<override> element; the two mechanisms aredistinct and unrelated.

[Definition:] A type definitionS isvalidly substitutable for another typeT, subject to aset of blocking keywordsK (typically drawn from the set{substitution,extension,restriction,list,union} used inthe{disallowed substitutions} and{prohibited substitutions} ofelement declarations and type definitions), if and only if either

S andT are both complex type definitions andS is validly derived fromT subject to the blocking keywords in the union ofK andT.{prohibited substitutions}, as defined inType Derivation OK (Complex) (§3.4.6.5)

S is a complex type definition,T is a simple type definition, andS is validly·derived· fromT subject to the blocking keywords inK, as defined inType Derivation OK (Complex) (§3.4.6.5)

S is a simple type definition andS is validly·derived· fromT subject to the blocking keywords inK, as defined inType Derivation OK (Simple) (§3.16.6.3).

[Definition:] If the set of keywords controlling whether a typeS is·validly substitutable· for another typeT is the empty set, thenS is said to bevalidlysubstitutable forTwithout limitation orabsolutely. The phrasevalidlysubstitutable, without mention of any set of blocking keywords, means "validly substitutable withoutlimitation".

Sometimes one typeS is·validly substitutable· for another typeT only ifS is derived fromT by a chain of restrictions, or ifT is a union type andS a member type of the union. The concept of·valid substitutability· is appealed to often enough in such contexts that it is convenient to define a term to cover this specific case.[Definition:] A type definitionS isvalidlysubstitutable as a restriction for another typeT if and only ifS is·validly substitutable· forT, subject to the blocking keywords {extension,list,union}.

3.3.4.3 Element Locally Valid (Element)

The concept of local validity of an element information item against an element declaration is an important part of the schema-validity·assessment· of elements. (The other important part is the recursive·assessment· of attributes and descendant elements.) Local validity partially determines the element information item's[validity] property, and fully determines the[local element validity] property, in the·post-schema-validation infoset·.

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).
Anyxsi:nil attribute on the element obeys the rules. The element is allowed to have anxsi:nil attribute only if the element is declared nillable, andxsi:nil = 'true' is allowed only if the element itself is empty. If the element declaration specifies a fixed value for the element,xsi:nil='true' will make the element invalid.
Anyxsi:type attribute present names a type which is·validly substitutable· for the element's declared{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·governing type definition·; additionally, if the element declaration specifies a fixed value, the content is checked against that value.
The element satisfies all the identity constraints specified on the element declaration.
Additionally, on the·validation root·, document-level ID and IDREF constraints are checked.

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 itemE to be locally·valid· with respect to an element declarationDall of the followingmust be true:

1D is not·absent· andE andD have the sameexpanded name.

2D.{abstract} =false.

3One of the following is true:

3.1D.{nillable} =false, andE has noxsi:nil attribute.

3.2D.{nillable} =true andone of the following is true

3.2.1E has noxsi:nil attribute information item.

3.2.2E hasxsi:nil =false.

3.2.3E hasxsi:nil=true(that is,E is·nilled·), andall of the following are true:

3.2.3.1E has no character or element information item[children].

3.2.3.2D has no{value constraint} with{variety} =fixed.

4 IfE has an·instance-specified type definition·T, thenT·overrides· the·selected type definition· ofE.

5The appropriatecase among the following is true:

5.1IfD has a{value constraint}, andE has neither element nor character[children], andE is not·nilled· with respect toD ,thenall of the following are true:

5.1.1IfE's·governing type definition· is an·instance-specified type definition·,thenD.{value constraint} is a valid default for the·governing type definition· as defined inElement Default Valid (Immediate) (§3.3.6.2).

5.1.2The element information item withD.{value constraint}.{lexical form} used as its·normalized value· islocally·valid· with respect tothe·governing type definition· as definedbyElement Locally Valid (Type) (§3.3.4.4).

5.2IfD has no{value constraint}, orE has either element or character[children], orE is·nilled· with respect toD,thenall of the following are true:

5.2.1E is locally·valid· with respect to the·governing type definition· as defined byElement Locally Valid (Type) (§3.3.4.4).

5.2.2 IfD.{value constraint}.{variety} =fixed andE is not·nilled· with respect toD, thenall of the following are true:

5.2.2.1E has no element information item[children].

5.2.2.2 The appropriatecase among the following is true:

5.2.2.2.1IfE's·governing type definition· is aComplex Type Definition with{content type}.{variety} =mixed ,thenthe·initial value· ofE matchesD.{value constraint}.{lexical form}.

5.2.2.2.2IfE's·governing type definition· is aSimple Type Definition or aComplex Type Definition with{content type}.{variety} =simple,thenthe·actual value· ofE is equal or identical toD.{value constraint}.{value}.

6E is·valid· with respect to each of the{identity-constraint definitions} as perIdentity-constraint Satisfied (§3.11.4).

7IfE is the·validation root·, then it is·valid· perValidation Root Valid (ID/IDREF) (§3.3.4.5).

Note: If an element has anxsi:type attribute, the type definition indicated by that attribute normally takes precedence over the·selected type definition· which would otherwise govern the element. If anxsi:type attribute is present and·resolves· to a known type definition, but fails to·override· the·selected type definition·, thenE is not locally valid againstD, sinceE has failed to satisfy clause4. In this case (or ifxsi:type fails to·resolve·), the·governing type definition· of the element is the·selected type definition· of its·governing element declaration·, and the element is validated against that type as described in clause5. The local validity of the element with respect to the·governing type definition· is recorded in the[local type validity] property. The use of the·selected type definition· when the·instance-specified type definition· cannot be used allows useful validation to proceed in some cases (not all) even when the schema is incomplete. It also helps ensure consistent typing for sub-elements with the same name.

3.3.4.4 Element Locally Valid (Type)

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·governing type definition·. It is also part of schema-validity·assessment· of an element when the element is·laxly assessed·, by checking its local validity againstxs: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 thexsi namespace) and child elements, and must be type-valid against that simple type definition. For a complex type definition, the element must be locally valid against that complex type definition.

Validation Rule: Element Locally Valid (Type)

For an element information itemE to be locally·valid· with respect to a type definitionTall of the followingmust be true:

1T is not·absent·;

2 IfT is a complex type definition, thenT.{abstract} =false.

3 The appropriatecase among the following is true:

3.1IfT is a simple type definition,thenall of the following are true:

3.1.1E.[attributes] is empty, except for attributes namedxsi:type,xsi:nil,xsi:schemaLocation, orxsi:noNamespaceSchemaLocation.

3.1.2E has no element information item[children].

3.1.3IfE is not·nilled·, then the·initial value· is·valid· with respect toT as defined byString Valid (§3.16.4).

3.2IfT is a complex type definition,thenE is locally·valid· with respect toT as perElement Locally Valid (Complex Type) (§3.4.4.2);

3.3.4.5 Validation Root Valid (ID/IDREF)

The following validation rule specifies document-level ID/IDREF constraints checked on the·validation root· if it is an element; this rule is not checked on other elements. Informally, the requirement is that each ID identifies a single element within the·validation root·, and that each IDREF value matches one ID.

Validation Rule: Validation Root Valid (ID/IDREF)

For an element information itemEwhich is the·validation root· to be·valid·all of the followingmust be true:

1There is noID/IDREF binding inE.[ID/IDREF table] whose[binding] is the empty set.

2There is noID/IDREF binding inE.[ID/IDREF table] whose[binding] has more than one member.

SeeID/IDREF Table (§3.17.5.2) for the definition ofID/IDREF binding.

Note: The first clause above isviolated when there is a reference to an undefinedID. The second is violated when there is a multiply-defined ID. The cases are separated out to ensure that distinct error codes (seeOutcome Tabulations (normative) (§B)) are associated with these two cases.

Note: Since an element governed by typexs:ID providesa unique identifier for the element's parent element, it is not usefulto have an element governed byxs:ID when the elementhas no parent element or when the parent element lies outside thescope of validation.

In the following examples,DOC andY are governed by type·xs:anyType·,the elementX and the attributexml:id are governed byxs:ID, and the elementZ is governed by a complex type with simple content derived fromxs:ID.

In the document<DOC><X>abcd</X></DOC>,the ID value 'abcd' will normally be bound totheDOC element. But if theXelement is the validation root, then 'abcd'will have no element binding, becauseDOCis outside the scope of the validation episode.So the first clause is violated and the document is invalid.
The superficially similar case<DOC><Y xml:id="abcd"/></DOC>will, in contrast, be valid whether theDOC elementor theY element is the validation root. TheID/IDREF table will have one entry in either case, binding'abcd' to theY element.
For the document<DOC><Zxml:id="abcd">abcd</Z></DOC>,ifZis the validation root, then the ID/IDREF table for the documentwill have a single entry for 'abcd' and will be valid. The single binding comes from thexml:id attribute; the content ofZ produces no binding, just as the content ofX above produces no binding.
But ifDOC is thevalidation root, then the ID/IDREF table for the document willhave two entries for 'abcd' (one, from thexml:id attribute, binding 'abcd' totheZ element, one from the content ofZ binding 'abcd' to theDOC element) andwill be invalid.

Note: Although this rule applies at the·validation root·, inpractice processors, particularly streaming processors,will perhaps wish to detect and signal theclause2 case as it arises.

Note: This reconstruction of[XML 1.1]'sID/IDREF functionality is imperfect in that ifthe·validation root· is not the document element of an XMLdocument, the results will not necessarily be the same asthose a validating parser would give were the document to havea DTD with equivalent declarations.

3.3.4.6 Schema-Validity Assessment (Element)

This section gives the top-level rule for·assessment· of an element information item. Informally:

Assessment begins with the identification of a·governing element declaration· for the element and then checks that the element is locally valid against the declaration; if no·governing element declaration· is available, a·governing type definition· can be used instead.
The element's attributes are to be·assessed· recursively, unless they match askip wildcard and are thus·skipped·.
The element's children are to be·assessed· recursively, unless they match askip wildcard and are thus·skipped·. For each child element, the·governing element declaration· is the one identified in the course of checking the local validity of the parent, unless that declaration is not available. If the·governing element declaration· is not available, the element may still be·strictly assessed· if a·governing type definition· can be identified (e.g. via thexsi:type attribute), otherwise the element will be·laxly assessed·.

[Definition:] Thegoverning element declaration ofan element information itemE, in a given schema-validity·assessment· episode, is the first of the followingwhich applies:

1A declaration stipulated by the processor (seeAssessing Schema-Validity (§5.2)).

2E's·context-determined declaration·.

3A declaration·resolved· to byE's[local name] and[namespace name], provided thatE is·attributed· either to astrict·wildcard particle· or to alax·wildcard particle·.

4A declaration·resolved· to byE's[local name] and[namespace name], provided thatnone of the following is true:

4.1E is·skipped·

4.2the processor has stipulated a type definition forE

4.3a·non-absent··locally declared type· exists forE

If none of these applies,E hasno·governing element declaration· (or, in equivalent words,E's·governing element declaration· is·absent·).

[Definition:] Thegoverning type definition of an element information itemE, in a given schema-validity·assessment· episode, is the first of the following which applies:

1An·instance-specified type definition· which·overrides· a type definition stipulated by the processor (seeAssessing Schema-Validity (§5.2)).

2A type definition stipulated by the processor (seeAssessing Schema-Validity (§5.2)).

3An·instance-specified type definition· which·overrides· the·selected type definition· ofE.

4The·selected type definition· ofE.

5The value·absent· ifE is·skipped·.

6 An·instance-specified type definition· which·overrides· the·locally declared type·.

7The·locally declared type·.

If none of these applies, there is no·governing type definition· (or, in equivalent words, it is·absent·).

Validation Rule: Schema-Validity Assessment (Element)

The schema-validity assessment of an element information itemE is performed as follows:

1IfE has a·governing element declaration· or a·governing type definition·, thenEmust be·strictly assessed·.

2IfE is·skipped·, thenEmust not be·assessed·.

3Otherwise,Emust be·laxly assessed·.

[Definition:] An elementinformation itemE is said to bestrictly assessedif and only ifall of the following are true:

1One of the following is true:

1.1All of the following are true:

1.1.1A·non-absent· element declaration is known forE, namely its·governing· declaration.

1.1.2E's local·validity· withrespect to that declaration has been evaluated as perElement Locally Valid (Element) (§3.3.4.3).

1.1.3If that evaluation involved the evaluation ofElement Locally Valid (Type) (§3.3.4.4), clause1 thereof is satisfied.

1.2All of the following are true:

1.2.1E does not have a·governing element declaration·.

1.2.2A·non-absent· type definition is known forE, namely its·governing type definition·

1.2.3The local·validity· ofE with respect to its·governing type definition· has been evaluated asperElement Locally Valid (Type) (§3.3.4.4).

2 For each of the attribute information items amongE.[attributes], the appropriatecase among the following is true:

2.1If the attribute has a·governing attribute declaration· ,then its schema-validity is assessed with respect to that declaration, as defined inSchema-Validity Assessment (Attribute) (§3.2.4.3).

2.2otherwise its schema-validity is not assessed.

3 For each of the element information items among its[children], the appropriatecase among the following is true:

3.1If the child has a·governing element declaration· or a·governing type definition· ,then its schema-validity is assessed with respect to that declaration or type definition, as defined inSchema-Validity Assessment (Element) (§3.3.4.6).

3.2If the child is·attributed to· askipWildcard ,then its schema-validity is not assessed.

3.3otherwise its schema-validity is·laxly assessed· with respect to·xs:anyType·.

[Definition:] The schema validity of an element information itemE is said to belaxly assessed if and only ifboth of the following are true:

1E has neither a·governing element declaration· nor a·governing type definition·.

2E is locally·validated· with respect to·xs:anyType· as defined inElement Locally Valid (Type) (§3.3.4.4), and the schema-validity ofE's[attributes] and[children] is assessed as described in clause2 and clause3 ofSchema-Validity Assessment (Element) (§3.3.4.6).

Note: It follows from the definitions given that no elementinformation item can be both·strictly assessed·and·laxly assessed· in the same schema-validity·assessment· episode.

3.3.5 Element Declaration Information Set Contributions

3.3.5.1 Assessment Outcome (Element)

Schema Information Set Contribution: Assessment Outcome (Element)

If and only if the schema-validity of an element information item has been assessed as perSchema-Validity Assessment (Element) (§3.3.4.6), then in the·post-schema-validation infoset· it has properties as follows:

PSVI Contributions for element information items

[validation context]: The nearest ancestor elementinformation item with a[schema information] property (or this element itemitself if it has such a property).
[validity]: The appropriatecase among the following:
1Ifit was·strictly assessed·,then the appropriatecase among the following:
1.1Ifall of the following are true:
1.1.1One of the following is true:
1.1.1.1clause1.1 ofSchema-Validity Assessment (Element) (§3.3.4.6) applied and the item was locally·valid· as defined byElement Locally Valid (Element) (§3.3.4.3);
1.1.1.2clause1.2 ofSchema-Validity Assessment (Element) (§3.3.4.6) applied and the item was locally·valid· as defined byElement Locally Valid (Type) (§3.3.4.4).
1.1.2Neither its[children] nor its[attributes] contains an information item (element or attribute respectively) whose[validity] isinvalid.
1.1.3Neither its[children] nor its[attributes] contains an information item (element or attribute respectively) which is·attributed· to astrict·wildcard particle· and whose[validity] isnotKnown.
thenvalid;
1.2otherwiseinvalid.
2otherwisenotKnown.
[validation attempted]: The appropriatecase among the following:
1Ifit was·strictly assessed· and neither its[children] nor its[attributes] contains an information item (element or attribute respectively) whose[validation attempted] is notfull,thenfull;
2Ifit was not·strictly assessed· and neither its[children] nor its[attributes] contains an information item (element or attribute respectively) whose[validation attempted] is notnone,thennone;
3otherwisepartial.

3.3.5.2 Validation Failure (Element)

Schema Information Set Contribution: Validation Failure (Element)

If and only if the local·validity·, as defined byElement Locally Valid (Element) (§3.3.4.3) above and/orElement Locally Valid (Type) (§3.3.4.4) below, of an element information item has been assessed, then in the·post-schema-validation infoset· the item has a property:

PSVI Contributions for element information items

[schema error code]: The appropriatecase among the following:
1Ifthe item is·invalid·,thena list. Applications wishing to provide information as to the reason(s) for the·validation· failure are encouraged to record one or more error codes (seeOutcome Tabulations (normative) (§B)) herein.
2otherwise·absent·.
[subsequence-valid]: The appropriatecase among the following:
1Ifthe element information item is locally·invalid·, because unexpected attributes or elements were found among its[attributes] and[children]and clause1 ofElement Locally Valid (Complex Type) (§3.4.4.2) would be satisfied, if those unexpected attributes and children (those with[match information] =none) were removed,thentrue
2otherwisefalse
[failed identity constraints]: A list ofIdentity-Constraint Definitions that are not satisfied by the element information item, as defined byIdentity-constraint Satisfied (§3.11.4).
Note: In principle, the value of this property includes all of theIdentity-Constraint Definitions which are not satisfied for this element item; in practice, some processors will expose a subset of the items in this value, rather than the full value. For example, a processor could choose not to check further identity constraints after detecting the first failure.
[failed assertions]: A list ofAssertions that are not satisfied by the element information item, as defined byAssertion Satisfied (§3.13.4.1).
Note: In principle, the value of this property includes all of theAssertions which are not satisfied by this element item; in practice, some processors will expose a subset of the items in this value, rather than the full value. For example, a processor could choose not to check further assertions after detecting the first failure.

3.3.5.3 Element Declaration

Schema Information Set Contribution: Element Declaration

If and only if a·governing element declaration· is knownfor an element information item, then in the·post-schema-validation infoset· the element information item has the properties:

PSVI Contributions for element information items

[element declaration]: an·item isomorphic· to the·governing· declarationcomponent itself
[nil]: true if clause3.2.3 ofElement Locally Valid (Element) (§3.3.4.3) above is satisfied,otherwisefalse
[expected element declaration]: if the element information item is·attributed· to an·element particle·, then the{term} of thatParticle, otherwise·absent·
Note: The[element declaration] either is the same as or is in the·substitution group· of the[expected element declaration].
[declared type]: an·item isomorphic·to the declared{type definition} of the·governing element declaration·
[local element validity]: The appropriatecase among the following:
1Ifthe item was locally·valid· as defined byElement Locally Valid (Element) (§3.3.4.3),thenvalid
2otherwise(the item was locally·invalid· as defined byElement Locally Valid (Element) (§3.3.4.3))invalid.

3.3.5.4 Element Validated by Type

Schema Information Set Contribution: Element Validated by Type

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

PSVI Contributions for element information items

[schema normalized value]

The appropriatecase among the following:

1Ifthe element information item is not·nilled· and either the·governing type definition· is a simple type definition or its{content type} has{variety}simple,then the appropriatecase among the following:

1.1If clause5.1 ofElement Locally Valid (Element) (§3.3.4.3) above has applied,then the{lexical form} of the{value constraint}

1.2If clause5.1 ofElement Locally Valid (Element) (§3.3.4.3) above hasnot applied and the element's·initial value· is·valid· with respect to the simple type definition as defined byString Valid (§3.16.4),then the·normalized value· of the item as·validated·

1.3otherwise·absent·.

2otherwise·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 orcomplex, depending on the[type definition].

[type definition namespace]

[type definition].{target namespace}.

[type definition anonymous]

true if[type definition].{name} is·absent·, otherwisefalse.

[type definition name]

If[type definition].{name} is not·absent·, then[type definition].{name}, otherwise schema processorsmay, 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 anxsi: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 anxsi: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 firstType Alternative that·successfully selected· the element's·selected type definition·, if any; otherwise the{default type definition}.

[local type validity]

The appropriatecase among the following:

1Ifthe element information item was locally·valid· as defined byElement Locally Valid (Type) (§3.3.4.4),thenvalid

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

[descendant validity]

The appropriatecase among the following:

1If neither its[children] nor its[attributes] contains an information itemI (element or attribute respectively) where eitherI's[validity] isinvalid orI is·attributed· to a strict·wildcard particle· andI's[validity] isnotKnown ,thenvalid;

2otherwiseinvalid.

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

Note: When clause5.1 ofElement Locally Valid (Element) (§3.3.4.3) above applies and the default or fixed value constraint{value} is of typeQName orNOTATION, 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.

If the[schema normalized value] is not·absent· andthe·governing type definition· is a simple type definition with{variety}union, or its{content type} has{variety}simple and{simple type definition} a simple type definition with{variety}union, then there are four additional properties:

PSVI Contributions for element information items

[member type definition]: An·item isomorphic· to the·validating type· of the[schema actual value].
[member type definition namespace]: The{target namespace} of the·validating type·.
[member type definition anonymous]: true if the{name} of the·validating type· is·absent·, otherwisefalse.
[member type definition name]: The{name} of the·validating type·, if it is not·absent·. If it is·absent·, schema processorsmay, butneed 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·.

The[type definition]property is provided for applications such as queryprocessors which need access to the full range of details aboutan item's·assessment·, forexample the type hierarchy; the[type definition type],[type definition namespace],[type definition name], and[type definition anonymous] properties are definedfor the convenience of those specifyinglighter-weight interfaces, in whichexposing the entire type hierarchy and full component detailsmight be a significantburden.

Ifall of the following are true:

1 the[schema normalized value] is not·absent·;

2One of the following is true:

2.1 the simple type definition used to validate the·normalized value· (either the·governing type definition· or its{simple type definition}) has{variety} =list;

2.2 the simple type definition has{variety} =union and the·validating type· of the[schema actual value] has{variety} =list;

3 the{item type definition} of the list type (from the previous clause) has{variety} =union;

then there is an additional property:

PSVI Contributions for element information items

[member type definitions]: a sequence ofSimple Type Definition components, with the same lengthas the[schema actual value], each one an·item isomorphic· to the·validating type· of the corresponding item in the[schema actual value].

Also, if the declaration has a{value constraint}, the item has a property:

PSVI Contributions for element information items

[schema default]: The{lexical form} of the declaration's{value constraint}.

Note that if an element is·laxly assessed·, then the[type definition] and[member type definition] properties, or their alternatives, are based on·xs:anyType·.

3.3.5.5 Element Default Value

Schema Information Set Contribution: Element Default Value

If and only if the local·validity·, as defined byElement Locally Valid (Element) (§3.3.4.3) above, of an element information item has been assessed, in the·post-schema-validation infoset· the item has a property:

PSVI Contributions for element information items

[schema specified]: The appropriatecase among the following:
1If clause5.1 ofElement Locally Valid (Element) (§3.3.4.3) above applies,thenschema.
2otherwiseinfoset.

See alsoMatch Information (§3.4.5.2),Identity-constraint Table (§3.11.5),Validated with Notation (§3.14.5), andSchema Information (§3.17.5.1), which describe other information set contributions related to element information items.

3.3.5.6 Inherited Attributes

Schema Information Set Contribution: Inherited Attributes

[Definition:] An attribute information itemA, whether explicitly specified in the input information set or defaulted as described inAttribute Default Value (§3.4.5.1), ispotentially inherited by an element information itemE if and only ifall of the following are true:

1A is among the[attributes] of one ofE's ancestors.

2A andE have the same[validation context].

3One of the following is true:

3.1A is·attributed to· anAttribute Use whose{inheritable} =true.

3.2A isnot·attributed to· anyAttribute Use butA has a·governing attribute declaration· whose{inheritable} =true.

If and only if an element information itemP is not·skipped· (that is, it is either·strictly· or·laxly· assessed), in the·post-schema-validation infoset· each ofP's element information item[children]E which is not·attributed to· askipWildcard, has a property:

PSVI Contributions for element information items

[inherited attributes]: A list of attribute information items. An attribute information itemA is included if and only ifall of the following are true:
1A is·potentially inherited· byE.
2 LetO beA's[owner element].A does not have the sameexpanded name as another attribute which is also·potentially inherited· byE and whose[owner element] is a descendant ofO.

3.3.6 Constraints on Element Declaration Schema Components

All element declarations (seeElement Declarations (§3.3))must satisfy the following constraint.

3.3.6.1 Element Declaration Properties Correct

Schema Component Constraint: Element Declaration Properties Correct

For any element declarationE,all of the followingmust be true:

1The values ofE's properties . are as described in the property tableau inThe Element Declaration Schema Component (§3.3.1), modulo the impact ofMissing Sub-components (§5.3).

2IfE has a·non-absent·{value constraint}, thenE.{value constraint} is a valid default with respect toE.{type definition} as defined inElement Default Valid (Immediate) (§3.3.6.2).

3IfE.{substitution group affiliations} is non-empty, thenE.{scope}.{variety} =global.

4For each memberM ofE.{substitution group affiliations},E.{type definition} is·validly substitutable· forM.{type definition}, subject to the blocking keywords inM.{substitution group exclusions}.

5There are no circular substitution groups. That is, it is not possible to return toE by repeatedly following any member of the{substitution group affiliations} property.

6IfE.{type table} exists, then for eachType Alternative inE.{type table}.{alternatives}, the{test} property is not·absent·.

7 IfE.{type table} exists, then for each{type definition}T inE.{type table}.{alternatives}, and also forE.{type table}.{default type definition}.{type definition},one of the following is true

7.1T is·validly substitutable· forE.{type definition}, subject to the blocking keywords ofE.{disallowed substitutions}.

7.2T is the type·xs:error·.

3.3.6.2 Element Default Valid (Immediate)

This and the following sections define relations appealed to elsewhere in this specification.

Schema Component Constraint: Element Default Valid (Immediate)

For aValue ConstraintVto be avalid default with respect to a type definitionTthe appropriatecase among the followingmust be true:

1IfT is a simple type definition or a complex type definition with{content type}.{variety} =simple ,thenV is a valid default with respect either toT (ifT is simple) or (ifT is complex) toT.{content type}.{simple type definition} as defined bySimple Default Valid (§3.2.6.2).

2IfT is a complex type definition with{content type}.{variety} ≠simple ,thenall of the following are true:

2.1T.{content type}.{variety} =mixed.

2.2The particleT.{content type}.{particle} is·emptiable· as defined byParticle Emptiable (§3.9.6.3).

3.3.6.3 Substitution Group OK (Transitive)

Schema Component Constraint: Substitution Group OK (Transitive)

For an element declaration (call itM, for member) to be substitutable for another element declaration (call itH, for head)at leastone of the followingmust be true:

1M andH are the same element declaration.

2All of the following are true:

2.1H.{disallowed substitutions} does not containsubstitution.

2.2There is a chain of{substitution group affiliations} properties fromM toH, that is, eitherM.{substitution group affiliations} containsH, orM.{substitution group affiliations} contains a declaration whose{substitution group affiliations} containsH, or . . .

2.3The set of all{derivation method}s involved in the·derivation· ofM.{type definition} fromH.{type definition} does not intersect with the union of (1)H.{disallowed substitutions}, (2)H.{type definition}.{prohibited substitutions} (ifH.{type definition} is complex, otherwise the empty set), and (3) the{prohibited substitutions} (respectively the empty set) of any intermediate declared{type definition}s in the·derivation· ofM.{type definition} fromH.{type definition}.

3.3.6.4 Substitution Group

[Definition:] One element declaration is substitutable for another if together they satisfy constraintSubstitution Group OK (Transitive) (§3.3.6.3).

[Definition:] Every element declaration (call thisHEAD) in the{element declarations} of a schema defines asubstitutiongroup, a subset of those{element declarations}. An element declaration is in thesubstitution group ofHEAD if and only if it is·substitutable· forHEAD.

3.4 Complex Type Definitions

Complex Type Definitions provide for:

Constraining element information items by providingAttribute Declaration (§2.2.2.3)s governing the appearance and content of[attributes]
Constraining element information item[children] to be empty,or to conform to a specified element-only or mixed content model, or elseconstraining the character information item[children] to conform to aspecified simple type definition.
Constraining elements and attributes to exist,not to exist, or to have specified values, withAssertion (§2.2.4.3)s.
Using the mechanisms ofType Definition Hierarchy (§2.2.1.1) to·derive· a complex type from another simple or complex type.
Specifying·post-schema-validation infoset contributions· for elements.
Limiting the ability to·derive· additional types from a given complex type.
Controlling the permission to substitute, in an instance, elements of a·derived·type for elements declared in a content model to be of a given complex type.

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.

3.4.1 The Complex Type Definition Schema Component

A complex type definition schema component has the followingproperties:

Schema Component:Complex Type Definition, a kind ofType Definition

{annotations}

A sequence ofAnnotation components.

{name}

An xs:NCName value. Optional.

{target namespace}

An xs:anyURI value. Optional.

{base type definition}

Atype definition component. Required.

{final}

A subset of {extension,restriction}.

{context}

Required if{name} is·absent·, otherwisemust be·absent·.

Either anElement Declaration or aComplex Type Definition.

{derivation method}

One of {extension,restriction}. Required.

{abstract}

An xs:boolean value. Required.

{attribute uses}

A set ofAttribute Use components.

{attribute wildcard}

AWildcard component. Optional.

{content type}

AContent Type property record. Required.

{prohibited substitutions}

A subset of {extension,restriction}.

{assertions}

A sequence ofAssertion components.

Property Record:Content Type

{variety}

One of {empty,simple,element-only,mixed}. Required.

{particle}

AParticle component. Required if{variety} iselement-only ormixed, otherwisemust be·absent·.

{open content}

AnOpen Content property record. Optional if{variety} iselement-only ormixed, otherwisemust be·absent·.

{simple type definition}

ASimple Type Definition component. Required if{variety} issimple, otherwisemust be·absent·.

Property Record:Open Content

{mode}

One of {interleave,suffix}. Required.

{wildcard}

AWildcard component. Required.

Complex type definitions are identified by their{name} and{target namespace}. Exceptfor anonymous complex type definitions (those with no{name}), sincetype definitions (i.e. both simple and complex type definitions taken together)must be uniquely identified within an·XSD schema·, no complex type definition can have the same name as anothersimple or complex type definition. Complex type{name}s and{target namespace}sare provided for reference frominstances (seexsi:type (§2.7.1)), and for use in the XMLrepresentation of schema components(specifically in<element>). SeeReferences to schema components across namespaces (<import>) (§4.2.6) for the use of componentidentifiers when importing one schema into another.

Note: The{name} of a complex type is notipsofacto the[(local) name] of the element information items·validated· by that definition. The connection between a name and a type definition is described inElement Declarations (§3.3).

As described inType Definition Hierarchy (§2.2.1.1), each complex type is·derived· from a{base type definition} which is itself either aSimple Type Definition (§2.2.1.2) or aComplex Type Definition (§2.2.1.3).{derivation method} specifies the means of·derivation· as eitherextension orrestriction (seeType Definition Hierarchy (§2.2.1.1)).

A complex type with an empty specification for{final} can be used as a{base type definition} for other types·derived· by either ofextension or restriction; the explicit valuesextension, andrestriction prevent further·derivations· by extension and restriction respectively. If all values are specified, then[Definition:] the complex type is said to befinal, because nofurther·derivations· are possible. Finality isnotinherited, that is, a type definition·derived· by restriction from a typedefinition which is final for extension is not itself, in the absence of anyexplicitfinal attribute of its own, final for anything.

The{context} property is only relevant for anonymous typedefinitions, for which its value is the component in which this typedefinition appears as the value of a property, e.g.{type definition}.

Complex types for which{abstract} istrue haveno valid instances and thus cannot be used in the normal way as the{type definition} for the·validation· of element information items (if for some reason an abstracttype is identified as the·governing type definition· of an elementinformation item, the item will invariably be invalid). Itfollows that suchabstract typesmust not be referenced from anxsi:type (§2.7.1) attribute in an instance document. Abstractcomplex types can be used as{base type definition}s, or even asthe declared{type definition}s of element declarations, provided in everycase a concrete·derived· type definition is used for·validation·, either viaxsi:type (§2.7.1) or the operation of a·substitution group·.

{attribute uses} are a set of attribute uses. SeeElement Locally Valid (Complex Type) (§3.4.4.2)andAttribute Locally Valid (§3.2.4.1) for details of attribute·validation·.

{attribute wildcard}s provide a more flexible specification for·validation· ofattributes not explicitly included in{attribute uses}.SeeElement Locally Valid (Complex Type) (§3.4.4.2),The Wildcard Schema Component (§3.10.1) andWildcard allows Expanded Name (§3.10.4.2) for formaldetails of attribute wildcard·validation·.

{content type} determines the·validation· of[children] of element information items. Informally:

A{content type} with{variety}empty·validates· elementswith no character or element information item[children].
A{content type} with{variety}simple·validates·elements with character-only[children]using its{simple type definition}.
A{content type} with{variety}element-only·validates· elements with[children] thatconform to the·content model· supplied by its{particle}.
A{content type} with{variety}mixed·validates· elements whose element[children] (i.e. specifically ignoring other[children] such as character information items)conform to the·content model· supplied by its{particle}.
A{content type} with·non-absent·{open content}·validates· elements with some[children] conforming to the·content model· and others conforming to the{open content}.

Note: Not all combinations of{derivation method} and{content type} are compatible with all properties of the{base type definition}. For example, it is not allowed to derive a complex type with complex content from a simple type. The XML mapping rules specified in the following section (in particular clause5 of the rule for the{simple type definition}in the rule for{content type}of complex types with simple content, and clause4.1 and clause4.2.1 of the rule for{content type} for complex types with complex content) do not detect such incompatible combinations of properties; in such cases the mapping rules will build a complex type regardless of the fact that the properties specified are incompatible. But the resulting complex type does not satisfy component rules outlined inDerivation Valid (Extension) (§3.4.6.2) orDerivation Valid (Restriction, Complex) (§3.4.6.3).

The{prohibited substitutions} property of a complex type definitionT determineswhether type definitions derived fromT are or are not·validly substitutable· forT. Examples include (but are not limitedto) the substitution of another type definition:

as the·governing type definition· of an element instanceE, whenT is the·selected type definition· ofE (often, the declared{type definition} ofE's·governing element declaration·); this can occur whenE specifies a type definition using thexsi:type attribute; seexsi:type (§2.7.1);
as the·selected type definition· of an element instanceE, whenT is the declared{type definition} ofE's·governing element declaration·; this can occur when conditional type assignment is used; seeType Alternatives (§3.12);
as the·governing type definition· of element instances whose·governing element declaration· is included in a model group only·implicitly·, by virtue of being included in the·substitution group· of some element declaration present·directly··indirectly· in the model group, whose declared{type definition} isT.
as the{type definition} of anElement DeclarationE1 where
- E1 is contained in aComplex Type DefinitionD
- D is derived from anotherComplex Type DefinitionB
- B contains anElement DeclarationE2 that has the sameexpanded name asE1
- E2 hasT as its{type definition}.

If{prohibited substitutions} is empty,then all such substitutions are allowed;if it contains the keywordrestriction, then no type definition is·validly substitutable· forT if its derivation fromT involvesany restriction steps;if{prohibited substitutions} contains the keywordextension, then no type definition is·validly substitutable· forT if its derivation fromT involvesany extension steps.

{assertions} constrain elements and attributesto exist, not to exist, or to have specified values.Though specified as a sequence, the orderamong the assertions is not significant during assessment.SeeAssertions (§3.13).

SeeAnnotations (§3.15) for information on the role of the{annotations} property.

3.4.2 XML Representation of Complex Type Definition Schema Components

The XML representation for a complex type definition schema component is a<complexType> element information item.

The XML representation for complex type definitions with a{content type} with{variety}simple is significantly different from that of those with other{content type}s, and this is reflected in the presentation below, which describes the mappings for the two cases in separate subsections. Common mapping rules are factored out and given in separate sections. As always, the mapping rules given here apply after, not before, the appropriate·pre-processing·.

XML Representation Summary:complexType Element Information Item

<complexType
 abstract =boolean : false
 block = (#all | List of (extension |restriction))
 final = (#all | List of (extension |restriction))
 id =ID
 mixed =boolean
 name =NCName
 defaultAttributesApply =boolean : true
 {any attributes with non-schema namespace . . .}>
 Content:(annotation?, (simpleContent |complexContent | (openContent?, (group |all |choice |sequence)?, ((attribute |attributeGroup)*,anyAttribute?),assert*)))
</complexType>

Note: It isa consequence of the concrete syntax given above that a top-level type definition need consist of no more than a name, i.e. that<complexType name="anyThing"/> is allowed.

Note: Aside from the simple coherence requirements outlined below, the requirement that type definitions identified as restrictions actuallybe restrictions — that is, the requirement that they accept as valid only a subset of the items which are accepted as valid by their base type definition — is enforced inConstraints 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> source declaration has a<simpleContent> element as a child, then it maps to aComplex Type Definition using the mapping rules in
If the<complexType> source declaration has a<complexContent> element as a child, then it maps to aComplex Type Definition using the mapping rules in
If the<complexType> source declaration has neither a<simpleContent> nor a<complexContent> element as a child, then it maps to aComplex Type Definition using the mapping rules in

Where convenient, the mapping rules are described exclusively in terms of the schema document's information set. The mappings, however, depend not only upon the source declaration but also upon the schema context. Some mappings, that is, depend on the properties of other components in the schema. In particular, several of the mapping rules given in the following sections depend upon the{base type definition} having been identified before they apply.

3.4.2.1 Common Mapping Rules for Complex Type Definitions

Whichever alternative for the content of<complexType> is chosen, the following property mappings apply.Except where otherwise specified, attributes and childelements are to be sought among the[attributes] and[children] of the<complexType> element.

XML Mapping Summary forComplex Type DefinitionSchema Component

Property

Representation

The·actual value· of thename[attribute] if present, otherwise·absent·.

{prohibited substitutions}

The·actual value· ofthetargetNamespace[attribute] of the<schema> ancestor element information item if present,otherwise·absent·.

{abstract}

The·actual value· of theabstract[attribute], if present, otherwisefalse.

A setcorresponding to the·actual value· of theblock[attribute], if present, otherwise to the·actual value· of theblockDefault[attribute] of the ancestor<schema> element information item, if present,otherwise on the empty string. Call this theEBV (for effective block value). Then thevalue of this property isthe appropriatecase among the following:

1IftheEBV is the empty string,thenthe empty set;

2IftheEBV is#all,then{extension,restriction};

3otherwisea set with members drawn from the set above, each being present or absent depending on whether the·actual value· (which is a list) contains an equivalently named item.

Note: Although theblockDefault[attribute] of<schema>may include values other thanrestriction orextension, those values are ignored in the determination of{prohibited substitutions} for complex type definitions (theyare used elsewhere).

As for{prohibited substitutions} above, but using thefinal andfinalDefault[attributes] in place of theblock andblockDefault[attributes].

If thename[attribute] is present, then·absent·, otherwise (among the ancestor element information items there will be a nearest<element>), theElement Declaration corresponding to the nearest<element> information item among the the ancestor element information items.

{assertions}

A sequence whose members areAssertions drawn from the following sources, in order:

1The{assertions} of the{base type definition}.

2Assertions corresponding to all the<assert> element information items among the[children] of<complexType>,<restriction> and<extension>, if any, in document order.

The·annotation mapping· of the set of elements containing the<complexType>, the<openContent>[child], if present, the<attributeGroup>[children], if present, the<simpleContent> and<complexContent>[children], if present, and their<restriction> and<extension>[children], if present, and their<openContent> and<attributeGroup>[children], if present, as defined inXML Representation of Annotation Schema Components (§3.15.2).

Note: If the{base type definition} is acomplex type definition, then the{assertions} alwayscontain members of the{assertions} of the{base type definition}, no matter whichalternatives are chosen in the XML representation,<simpleContent> or<complexContent>,<restriction> or<extension>.

3.4.2.2 Mapping Rules for Complex Types with Simple Content

When the<complexType>source declaration has a<simpleContent> child, the following elements are relevant (as are<attribute>,<attributeGroup>, and<anyAttribute>), and the property mappings are as below,supplemented by the mappings inCommon Mapping Rules for Complex Type Definitions (§3.4.2.1),Mapping Rule for Attribute Uses Property (§3.4.2.4),andMapping Rule for Attribute Wildcard Property (§3.4.2.5). Note that either<restriction> or<extension>must appear in the content of<simpleContent>.

XML Representation Summary:simpleContent Element Information Item et al.

<simpleContent
 id =ID
 {any attributes with non-schema namespace . . .}>
 Content:(annotation?, (restriction |extension))
</simpleContent>

<restriction
 base =QName
 id =ID
 {any attributes with non-schema namespace . . .}>
 Content:(annotation?, (simpleType?, (minExclusive |minInclusive |maxExclusive |maxInclusive |totalDigits |fractionDigits |length |minLength |maxLength |enumeration |whiteSpace |pattern |assertion |{any with namespace: ##other})*)?, ((attribute |attributeGroup)*,anyAttribute?),assert*)
</restriction>

<extension
 base =QName
 id =ID
 {any attributes with non-schema namespace . . .}>
 Content:(annotation?, ((attribute |attributeGroup)*,anyAttribute?),assert*)
</extension>

When the<complexType>element has a<simpleContent> child, then the<complexType> element maps to a complex type with simple content, as follows.

XML Mapping Summary forComplex Type Definition with simple contentSchema Component

Property

Representation

The typedefinition·resolved· to by the·actual value· of thebase[attribute] on the<restriction> or<extension> element appearing as a child of<simpleContent>

If the<restriction> alternativeis chosen, thenrestriction, otherwise (the<extension> alternative ischosen)extension.

{content type}

AContent Type as follows:

Property

Value

simple

the appropriatecase among the following:

1Ifthe{base type definition} is a complex type definition whose own{content type} has{variety}simple and the<restriction> alternative is chosen,then letB be

1.1the simple type definition corresponding to the<simpleType> among the[children] of<restriction> if there is one;

1.2otherwise (<restriction> has no<simpleType> among its[children]), thesimple type definition which is the{simple type definition} of the{content type} ofthe{base type definition}

a simple type definition as follows:

Property

Value

The·actual value· of thetargetNamespace[attribute] of the ancestor<schema> element information item if present, otherwise·absent·

The empty set

TheComplex Type Definition whose{content type}.{simple type definition} is being defined

B

a set of facet components corresponding to the appropriate element information items among the<restriction>'s[children] (i.e. those which specify facets, if any), as defined inSimple Type Restriction (Facets) (§3.16.6.4);

Based on{variety},{facets},{base type definition} and{member type definitions}, a set ofFundamental Facet components, one each as specified inThe ordered Schema Component,The bounded Schema Component,The cardinality Schema Component andThe numeric Schema Component

B.{variety}

B.{primitive type definition}

B.{item type definition}

B.{member type definitions}

The empty sequence

2Ifthe{base type definition} is a complex type definition whose own{content type} has{variety}mixed and{particle} aParticle which is·emptiable·, as defined inParticle Emptiable (§3.9.6.3) and the<restriction> alternative is chosen,then (letS_B be the simple type definition corresponding to the<simpleType> among the[children] of<restriction> if any, otherwise·xs:anySimpleType·) a simple type definition which restrictsS_B with a set of facet components corresponding to the appropriate element information items among the<restriction>'s[children] (i.e. those which specify facets, if any), as defined inSimple Type Restriction (Facets) (§3.16.6.4);

Note: If there is no<simpleType> among the[children] of<restriction> (and if thereforeS_B is·xs:anySimpleType·), the result will be a simple type definition component which fails to obey the constraints on simple type definitions, including for example clause1.1 ofDerivation Valid (Restriction, Simple) (§3.16.6.2).

3Ifthe{base type definition} is a complex type definition whose own{content type} has{variety}simple and the<extension> alternative is chosen,then the{simple type definition} of the{content type} of that complex type definition;

4Ifthe{base type definition} is a simple type definition and the<extension> alternative is chosen,thenthat simple type definition;

5otherwise·xs:anySimpleType·.

3.4.2.3 Mapping Rules for Complex Types with Complex Content

When the<complexType>element does not have a<simpleContent> childelement, then it maps to a complex type with complexcontent. The following elements are relevant (as are the<attribute>,<attributeGroup>, and<anyAttribute> elements, which are described more fully inXML Representation of Attribute Declaration Schema Components (§3.2.2),Mapping Rule for Attribute Uses Property (§3.4.2.4), andXML Representation of Wildcard Schema Components (§3.10.2), respectively, and which are not repeated here), and the additional property mappings are as below, supplementedby the mappings inCommon 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), andMapping Rules for References to Top-level Attribute Declarations (§3.2.2.3). Note that either<restriction> or<extension>must appear in the content of<complexContent>, but their content models are different in this case from the case above when they occur as children of<simpleContent>.

XML Representation Summary:complexContent Element Information Item et al.

<complexContent
 id =ID
 mixed =boolean
 {any attributes with non-schema namespace . . .}>
 Content:(annotation?, (restriction |extension))
</complexContent>

<restriction
 base =QName
 id =ID
 {any attributes with non-schema namespace . . .}>
 Content:(annotation?,openContent?, (group |all |choice |sequence)?, ((attribute |attributeGroup)*,anyAttribute?),assert*)
</restriction>

<extension
 base =QName
 id =ID
 {any attributes with non-schema namespace . . .}>
 Content:(annotation?,openContent?, ((group |all |choice |sequence)?, ((attribute |attributeGroup)*,anyAttribute?),assert*))
</extension>

<openContent
 id =ID
 mode = (none |interleave |suffix) : interleave
 {any attributes with non-schema namespace . . .}>
 Content:(annotation?,any?)
</openContent>

Complex types with complex content can be the image of two different forms of<complexType> element: one with a<complexContent> child (discussed inMapping Rules for Complex Types with Explicit Complex Content (§3.4.2.3.1)), and one with neither<simpleContent> nor<complexContent> as a child (discussed inMapping Rules for Complex Types with Implicit Complex Content (§3.4.2.3.2)). The mapping of the{content type} is the same in both cases; it is described inMapping Rules for Content Type Property of Complex Content (§3.4.2.3.3).

3.4.2.3.1 Mapping Rules for Complex Types with Explicit Complex Content

When the<complexType>source declaration has a<complexContent>child, the following mappings apply, supplemented by thosespecified inMapping 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), andMapping Rule for Attribute Wildcard Property (§3.4.2.5).

XML Mapping Summary forComplex Type Definition with complex contentSchema Component

Property

Representation

The type definition·resolved· to by the·actual value· of thebase[attribute]

If the<restriction> alternative is chosen, thenrestriction, otherwise (the<extension> alternative is chosen)extension.

3.4.2.3.2 Mapping Rules for Complex Types with Implicit Complex Content

When the<complexType> source declarationhas neither<simpleContent> nor<complexContent> as a child, it is takenas shorthand for complex content restricting·xs:anyType·. The mapping rules specific to thissituation are as follows; the mapping rules for propertiesnot described here are as given inMapping 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), andMapping Rule for Attribute Wildcard Property (§3.4.2.5).

XML Mapping Summary forComplex Type Definition with complex contentSchema Component

Property

Representation

·xs:anyType·

restriction

3.4.2.3.3 Mapping Rules for Content Type Property of Complex Content

For complex types with complex content,the{content type} property iscalculated as follows. (For the{content type} on complex types with simple content,seeMapping Rules for Complex Types with Simple Content (§3.4.2.2).)

Note: The mapping rule below refers here and there to elements not necessarily present within a<complexType> source declaration. For purposes of evaluating tests like "If theabc attribute is present on thexyz element", if noxyz element information item is present, then noabc attribute is present on the (non-existent)xyz element.

When the mapping rule below refers to "the[children]", then for a<complexType> source declaration with a<complexContent> child, then the[children] of<extension> or<restriction> (whichever appears as a child of<complexContent>) are meant. If no<complexContent> is present, then the[children] of the<complexType> source declaration itself are meant.

The mapping rule also refers to the value of the{derivation method} property, whose value is determined as specified in the preceding sections.

XML Mapping Summary forComplex Type Definition with complex contentSchema Component

Property

Representation

{content type}

1[Definition:] Let theeffective mixed be the appropriatecase among the following:

1.1Ifthemixed[attribute] ispresent on<complexContent>,thenits·actual value·;

1.2Ifthemixed[attribute] ispresent on<complexType>,thenits·actual value·;

1.3otherwisefalse.

Note: It is a consequence of clause5 ofComplex Type Definition Representation OK (§3.4.3) that clause1.1 and clause1.2 above will never contradict each other in a conforming schema document.

2[Definition:] Let theexplicit content be the appropriatecase among the following:

2.1If at leastone of the following is true

2.1.1There is no<group>,<all>,<choice> or<sequence> among the[children];

2.1.2There is an<all> or<sequence> among the[children] with no[children] of its own excluding<annotation>;

2.1.3There is among the[children] a<choice> element whoseminOccurs[attribute] has the·actual value·0 and which has no[children] of its own except for<annotation>;

2.1.4The<group>,<all>,<choice> or<sequence> element among the[children] has amaxOccurs[attribute] with an·actual value· of 0;

thenempty

2.2otherwisethe particle corresponding to the<all>,<choice>,<group> or<sequence> among the[children].

3[Definition:] Let theeffective content bethe appropriatecase among the following:

3.1If the·explicit content· isempty ,thenthe appropriatecase among the following:

3.1.1Ifthe·effective mixed· istrue,thenA particle whose properties are as follows:

Property

Value

a model group whose{compositor} issequence and whose{particles} is empty.

3.1.2otherwiseempty

3.2otherwisethe·explicit content·.

4[Definition:] Let theexplicit content type be the appropriatecase among the following:

4.1If{derivation method} =restriction,thenthe appropriatecase among the following:

4.1.1Ifthe·effective content· isempty ,thenaContent Type as follows:

Property

Value

empty

4.1.2otherwiseaContent Type as follows:

Property

Value

mixed if the·effective mixed· istrue, otherwiseelement-only

The·effective content·

{open content}

4.2If{derivation method} =extension,thenthe appropriatecase among the following:

4.2.1Ifthe{base type definition} is a simple type definition or is a complex type definition whose{content type}.{variety} =empty orsimple,thenaContent Type as per clause4.1.1 and clause4.1.2 above;

4.2.2Ifthe{base type definition} is a complex type definition whose{content type}.{variety} =element-only ormixed and the·effective content· isempty,then{base type definition}.{content type};

4.2.3otherwiseaContent Type as follows:

Property

Value

mixed if the·effective mixed· istrue, otherwiseelement-only

[Definition:] Let thebase particle be the particle of the{content type} of the{base type definition}. Then the appropriatecase among the following:

4.2.3.1Ifthe{term} ofthe·base particle· has{compositor}all and the·explicit content· is empty,thenthe·base particle·.

4.2.3.2Ifthe{term} ofthe·base particle· has{compositor}all and the{term} of the·effective content· also has{compositor}all,thenaParticle whose properties areas follows:

the{min occurs} of the·effective content·.

1

a model group whose{compositor} isall and whose{particles} are the{particles} of the{term} of the·base particle· followed by the{particles} of the{term} of the·effective content·.

4.2.3.3otherwise

1

1

a model group whose{compositor} issequence and whose{particles} are the·base particle· followed by the·effective content·.

{open content}

the{open content} of the{content type} of the{base type definition}.

5[Definition:] Let thewildcard element be the appropriatecase among the following:

5.1Ifthe<openContent>[child] is present ,thenthe<openContent>[child].

5.2Ifthe<openContent>[child] is notpresent, the<schema> ancestor has a<defaultOpenContent>[child], andone of the following is true

5.2.1 the·explicit content type· has{variety} ≠empty

5.2.2 the·explicit content type· has{variety} =empty and the<defaultOpenContent> element hasappliesToEmpty =true

thenthe<defaultOpenContent>[child] of the<schema>.

5.3otherwise·absent·.

6 Then the value of the property is the appropriatecase among the following:

6.1Ifthe·wildcard element· is·absent·or is present and hasmode ='none' ,thenthe·explicit content type·.

6.2otherwise

Property

Value

The{variety} of the·explicit content type· if it's notempty; otherwiseelement-only.

The{particle} of the·explicit content type· if the{variety} of the·explicit content type· is notempty; otherwise aParticle as follows:

Property

Value

a model group whose{compositor} issequence and whose{particles} is empty.

{open content}

AnOpen Content as follows:

Property

Value

{mode}

The·actual value· of themode[attribute] of the·wildcard element·, if present, otherwiseinterleave.

{wildcard}

LetW be the wildcard corresponding to the<any>[child] of the·wildcard element·. If the{open content} of the·explicit content type· is·absent·, thenW; otherwise a wildcard whose{process contents} and{annotations} arethose ofW, and whose{namespace constraint} is the wildcard union of the{namespace constraint} ofW and of{open content}.{wildcard} of the·explicit content type·, as defined inAttribute Wildcard Union (§3.10.6.3).

[schema normalized value]

Note: It is a consequence of clause4.2 above that when a type definition is extended, the same particles appear in both the base type definition and the extension; the particles are reused without being copied.

3.4.2.4 Mapping Rule for Attribute Uses Property

Any<complexType> source declaration can have<attribute> and<attributeGroup> elements as children, or descendants. The<attribute> element is described inXML Representation of Attribute Declaration Schema Components (§3.2.2) and will not be repeated here.

XML Representation Summary:attributeGroup Element Information Item

<attributeGroup
 id =ID
 ref =QName
 {any attributes with non-schema namespace . . .}>
 Content:(annotation?)
</attributeGroup>

The<attribute> and<attributeGroup> elements map to the{attribute uses} property of theComplex Type Definition component as described below. This mapping rule is the same for all complex type definitions.

Note: In the following rule, references to "the[children]" refer to the[children] ofthe<extension>or<restriction> element (whicheverappears as a child of<simpleContent> or<complexContent> in the<complexType> source declaration),if present, otherwise to the[children] of the<complexType> source declaration itself.

The rule also refers to the value of the{derivation method}property, which is described elsewhere.

XML Mapping Summary forComplex Type Definition (Attribute Uses)Schema Component

Property

Representation

{attribute uses}

If the<schema> ancestor has adefaultAttributes attribute, and the<complexType> element does not havedefaultAttributesApply =false, then the{attribute uses} property is computed as if there were an<attributeGroup>[child] with empty content and aref[attribute] whose·actual value· is the same as that of thedefaultAttributes[attribute] appearing after any other<attributeGroup>[children]. Otherwise proceed as if there were no such<attributeGroup>[child].

Then the value is a union of sets of attribute uses as follows

1The set of attribute uses corresponding to the<attribute>[children], if any.

2The{attribute uses} of the attribute groups·resolved· to by the·actual value·s of theref[attribute] of the<attributeGroup>[children], if any.

3 The attribute uses "inherited" from the{base type definition}T, as described by the appropriatecase among the following:

3.1IfT is a complex type definition and{derivation method} =extension,thenthe attribute uses inT.{attribute uses} are inherited.

3.2IfT is a complex type definition and{derivation method} =restriction,thenthe attribute uses inT.{attribute uses} are inherited, with the exception of those with an{attribute declaration} whoseexpanded name isone of the following:

3.2.1theexpanded name of the{attribute declaration} of an attribute use which has already been included in the set, following the rules in clause1 or clause2 above;

3.2.2theexpanded name of the{attribute declaration} of what would have been an attribute use corresponding to an<attribute>[child], if the<attribute> had not haduse =prohibited.

Note: This sub-clause handles the case where the base type definitionT allows the attribute in question, but the restriction prohibits it.

3.3otherwiseno attribute use is inherited.

Note: Theonly substantive function of the valueprohibited for theuse attribute of an<attribute> is inestablishing the correspondence between a complex type definedby restriction and its XML representation. It serves toprevent inheritance of an identically named attribute use fromthe{base type definition}. Such an<attribute> does not correspond to any component, andhence there is no interaction with either explicit orinherited wildcards in the operation ofComplex Type Definition Validation Rules (§3.4.4) orConstraints on Complex Type Definition Schema Components (§3.4.6).It is pointless, though not an error, for theuse attribute to have the valueprohibited in other contexts (e.g. in complex type extensions or named model group definitions), in which cases the <attribute> element is simply ignored, provided that it does not violate other constraints in this specification.

3.4.2.5 Mapping Rule for Attribute Wildcard Property

The{attribute wildcard} property of aComplex Type Definition depends on the<anyAttribute> element which may be present within the<complexType> element or within the attribute groups referred to within<complexType>. The<attributeGroup> element is described in the preceding sectionMapping Rule for Attribute Uses Property (§3.4.2.4) and will not be repeated here.

Note: The following mapping ruleis the same for all complex type definitions.

References to "the[children]" refer to the[children] ofthe<extension>or<restriction> element (whicheverappears as a child of<simpleContent> or<complexContent> in the<complexType> source declaration),if present, otherwise to the[children] of the<complexType> source declaration itself.

The rule also refers to the value of the{derivation method}property, which is described elsewhere.

XML Mapping Summary forComplex Type Definition (Attribute Wildcard)Schema Component

Property

Representation

{attribute wildcard}

If the<schema> ancestor has adefaultAttributes attribute, and the<complexType> element does not havedefaultAttributesApply =false, then the{attribute wildcard} property is computed as if there were an<attributeGroup>[child] with empty content and aref[attribute] whose·actual value· is the same as that of thedefaultAttributes[attribute] appearing after any other<attributeGroup>[children]. Otherwise proceed as if there were no such<attributeGroup>[child].

1[Definition:] Let thecomplete wildcard be theWildcard computed as described inCommon Rules for Attribute Wildcards (§3.6.2.2).

2 The value is then determined by the appropriatecase among the following:

2.1If{derivation method} =restriction,thenthe·completewildcard·;

2.2If{derivation method} =extension,then

2.2.1[Definition:] let thebase wildcard be defined as the appropriatecase among the following:

2.2.1.1Ifthe{base type definition} is a complex type definition with an{attribute wildcard},thenthat{attribute wildcard}.

2.2.1.2otherwise·absent·.

2.2.2 The value is then determined by the firstcase among the following which applies:

2.2.2.1Ifthe·base wildcard· is·absent·,thenthe·complete wildcard·;

2.2.2.2Ifthe·complete wildcard· is·absent·,thenthe·base wildcard·;

2.2.2.3otherwise a wildcard whose{process contents} and{annotations} are those of the·complete wildcard·, and whose{namespace constraint} is thewildcardunion of the{namespace constraint} of the·complete wildcard· and of the·base wildcard·, as defined inAttribute Wildcard Union (§3.10.6.3).

3.4.2.6 Examples of Complex Type Definitions

Example: Three ways to define a type for length

The following declaration defines a type for specifications of lengthby creating a complex type with simple content, withxs:nonNegativeInteger as the type of the content, and aunit attribute to give theunit of measurement.

<xs:complexType name="length1"> <xs:simpleContent>  <xs:extension base="xs:nonNegativeInteger">   <xs:attribute name="unit" type="xs:NMTOKEN"/>  </xs:extension> </xs:simpleContent></xs:complexType><xs:element name="width" type="length1"/>

An instance using this type might look like this:

  <width unit="cm">25</width>

A second approach to defining lengthuses two elements, one for size and one for the unit of measure. The definition of the type and thedeclaration 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 typeimplicit; at the component level, the following declarationis 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·derived· byextension which adds a single element; an element declaration referencing the·derived· definition, and a·valid· instance thereof.

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·derived· from the base type from the previous example by restriction, eliminating one optional child andfixing another to occur exactly once; an element declared by reference to it,and a·valid· instance thereof.

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 themixed attribute appearing oncomplexType itself.

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·competes· with a wildcard, use a wildcard in the derived type that explicitly disallows the element'sexpanded name. For example:

<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 typequietComputer has alax wildcard, which·matches· any element but one with the namespeaker.

Without the specification of thenotQName attribute, the wildcard would·match· elements namedspeaker, as well. In that case, the restriction would be valid only if there is a top-level declaration forspeaker that also has typespeakerType or a type derived from it. Otherwise, there would be instances locally valid against the restrictionquietComputer that are not locally valid against the base typecomputer.

For example, if there is nonotQName attribute on the wildcard and no top-level declaration forspeaker, then the following is allowed byquietComputer, but not bycomputer:

   <speaker xsi:type="xs:string"/>

The specific rule violated in this case is clause2 of constraintContent type restricts (Complex Content) (§3.4.6.4)

3.4.3 Constraints on XML Representations of Complex Type Definitions

Schema Representation Constraint: Complex Type Definition Representation OK

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

1If the<simpleContent> alternative is chosen, the<complexType> elementmust not havemixed =true.

2 If<restriction> is present under<simpleContent>, then no facet-specifying element other thanxs:enumeration,xs:pattern, orxs:assertionmay appear more than once among the[children] of<restriction>.

3 If<openContent> is present and hasmode ≠'none', then theremust be an<any> among the[children] of<openContent>.

4If<openContent> is present and hasmode ='none', then theremust not be an<any> among the[children] of<openContent>.

5 If the<complexContent> alternative is chosen and themixed[attribute] is present on both<complexType> and<complexContent>, then·actual values· of those[attributes]must be the same.

3.4.4 Complex Type Definition Validation Rules

3.4.4.1 Locally Declared Type

This section defines the concept of·locally declared type·; this concept plays a role in determining whether restrictions and extensions of complex type definitions are legitimate. The·locally declared type· is also used to help determine the·governing element declaration· and·governing type definition· of an element information item.

[Definition:] EveryComplex Type Definition determines a partial functional mapping fromelement or attributeinformation items (and theirexpanded names) to typedefinitions. This mapping serves as alocally declared type for elements and attributes which are allowed bytheComplex Type Definition.

The attribute case is simpler and will be taken first.

[Definition:] For a givenComplex Type DefinitionCTD and a given attributeinformation itemA, the·locally declared type· ofA withinCTD isthe appropriatecase among the following:

1IfCTD is·xs:anyType· ,then·absent·.

2IfA has the sameexpanded name as some attribute declarationD which is the{attribute declaration} of someAttribute Use contained byCTD's{attribute uses} ,then the{type definition} ofD.

3otherwise the·locally declared type· ofA withinCTD.{base type definition}.

The definition for elements is slightlymore complex.

[Definition:] For a givenComplex Type DefinitionCTD and a given element information itemE, the·locally declared type· ofE withinCTD is the appropriatecase among the following:

1IfCTD is·xs:anyType· ,then·absent·.

2IfE has the sameexpanded name as some element declarationD which is·contained· byCTD's content model, whether·directly·,·indirectly·, or·implicitly· ,then the declared{type definition} ofD.

3otherwise the·locally declared type· ofE withinCTD.{base type definition}.

Note: The constraintElement Declarations Consistent (§3.8.6.3) ensures that even if there is more than one such declarationD, there will be just one type definition.

Note: The reference to·implicit· containment ensures that ifE has a·governing element declaration··substitutable· for a declaration·contained· byCTD's content model, a·locally declared type· is defined forE.

3.4.4.2 Element Locally Valid (Complex Type)

Validation Rule: Element Locally Valid (Complex Type)

For an element information itemE to be locally·valid· with respect to a complex type definitionTall of the followingmust be true:

1IfE is not·nilled·, thenall of the following are true:

1.1IfT.{content type}.{variety} =empty,thenE has no character or element information item[children].

1.2IfT.{content type}.{variety} =simple,thenE has no element information item[children], and the·initial value· ofE is·valid· with respect toT.{content type}.{simple type definition} as defined byString Valid (§3.16.4).

1.3IfT.{content type}.{variety} =element-only,thenE has no character information item[children] other than those whose[character code] is defined as awhite space in[XML 1.1].

1.4IfT.{content type}.{variety} =element-only orT.{content type}.{variety} =mixed,thenthe sequence of element information items inE.[children], if any, taken in order, is·valid· with respect toT.{content type}, as defined inElement Sequence Locally Valid (Complex Content) (§3.4.4.3).

2For each attribute information itemA inE.[attributes] excepting those namedxsi:type,xsi:nil,xsi:schemaLocation, orxsi:noNamespaceSchemaLocation (seeBuilt-in Attribute Declarations (§3.2.7)), the appropriatecase among the following is true:

2.1Ifthere is among the{attribute uses} an attribute useU whose{attribute declaration} has the sameexpanded name asA ,thenA is locally·valid· with respect toU as perAttribute Locally Valid (Use) (§3.5.4). In this caseU.{attribute declaration} is the·context-determined declaration· forA with respect toSchema-Validity Assessment (Attribute) (§3.2.4.3) andAssessment Outcome (Attribute) (§3.2.5.1). AlsoA is·attributed to·U.

2.2otherwiseall of the following are true:

2.2.1There is an{attribute wildcard}.

2.2.2A is·valid· with respect to it as defined inItem Valid (Wildcard) (§3.10.4.1).

In this caseA is·attributed to· the{attribute wildcard}.

3For each attribute useU inT.{attribute uses}, ifU.{required} =true, thenU.{attribute declaration} has the sameexpanded name as one of the attribute information items inE.[attributes].

Note: It is a consequence that (with few exceptions) each suchU will have the matching attribute information item·attributed to· it by clause2.1 above. The exceptions are uses ofxsi:type and the other attributes named in clause2.1; no·attribution· is performed for them.

4 For each·defaulted attribute·A belonging toE, the{lexical form} ofA's·effective value constraint· is·valid· with respect toA.{attribute declaration}.{type definition} as defined byString Valid (§3.16.4).

Note: When an{attribute wildcard} is present, this doesnot introduce any ambiguity with respect to how attribute information items for which an attribute use is present amongst the{attribute uses} whose name and target namespace match are·assessed·. In such cases the attribute usealways takes precedence, and the·assessment· of such items stands or falls entirely on the basis of the attribute use and its{attribute declaration}. This follows from the details of clause2.

5 For each element information item inE.[children] and each attribute information item inE.[attributes], if neither the·governing type definition· nor the·locally declared type· is·absent·, then the·governing type definition· is the same as, or is·validly substitutable· for, the·locally declared type·,·without limitation·.

6E is·valid· with respect to each of the assertions inT.{assertions} as perAssertion Satisfied (§3.13.4.1).

[Definition:] Adefaulted attribute belonging to an element information itemE·governed by· a complex typeTis anyAttribute UseUfor whichall of the following are true:

1U is a member ofT.{attribute uses}.

2U.{required} =false.

3U's·effective value constraint· is not·absent·.

4U.{attribute declaration} is not one of theAttribute Declarations fromBuilt-in Attribute Declarations (§3.2.7).

5U.{attribute declaration} does not match any of the attribute information items inE.[attributes] as per clause2.1 ofElement Locally Valid (Complex Type) (§3.4.4.2) above.

3.4.4.3 Element Sequence Locally Valid (Complex Content)

Validation Rule: Element Sequence Locally Valid (Complex Content)

For a sequenceS (possibly empty) of element information items to be locally·valid· with respect to aContent TypeCT,the appropriatecase among the followingmust be true:

1IfCT.{open content} is·absent· ,thenS is·valid· with respect toCT.{particle}, as defined inElement Sequence Locally Valid (Particle) (§3.9.4.2).

2IfCT.{open content}.{mode} =suffix ,thenS can be represented as two subsequencesS1 andS2 (either can be empty) such thatall of the following are true:

2.1S =S1 +S2

2.2S1 is·valid· with respect toCT.{particle}, as defined inElement Sequence Locally Valid (Particle) (§3.9.4.2).

2.3 IfS2 is not empty, letE be the first element inS2, thenS1 +E doesnot have a·path· inCT.{particle}

2.4 Every element inS2 is·valid· with respect to the wildcardCT.{open content}.{wildcard}, as defined inItem Valid (Wildcard) (§3.10.4.1).

3otherwise (CT.{open content}.{mode} =interleave)S can be represented as two subsequencesS1 andS2 (either can be empty) such thatall of the following are true:

3.1S is a member ofS1 ×S2 (where × is the interleave operator, seeAll-groups (§3.8.4.1.3))

3.2S1 is·valid· with respect toCT.{particle}, as defined inElement Sequence Locally Valid (Particle) (§3.9.4.2).

3.3 For every elementE inS2, letS3 be the longest prefix ofS1 where members ofS3 are beforeE inS, thenS3 +E doesnot have a·path· inCT.{particle}

3.4 Every element inS2 is·valid· with respect to the wildcardCT.{open content}.{wildcard}, as defined inItem Valid (Wildcard) (§3.10.4.1).

[Definition:] A sequence of element information items islocally valid with respect to aContent Type if and only if it satisfiesElement Sequence Locally Valid (Complex Content) (§3.4.4.3) with respect to thatContent Type.

3.4.4.4 Attribution

[Definition:] During·validation· of an element information item against its (complex)·governing type definition·, associations between element and attribute information items among the[children] and[attributes] on the one hand, and the attribute uses, attribute wildcard, particles and open content property record on the other, are established. The element or attribute information item isattributed to the corresponding component.

When an attribute information item has the sameexpanded name as the{attribute declaration} of anAttribute Use, then the item isattributed to that attribute use. Otherwise, if the item matches an attribute wildcard, as described inItem Valid (Wildcard) (§3.10.4.1), then the item isattributed to that wildcard. Otherwise the item isnotattributed to any component.

When a sequenceS of[child] element information items are checked against the·governing type definition·'s{content type}CT, letS1 andS2 be subsequences ofS such that

S is a member ofS1 ×S2
S1 is a prefix of some element sequence that is·locally valid· with respect toCT, as defined inElement Sequence Locally Valid (Complex Content) (§3.4.4.3).
for every elementE inS2, letS3 be the longest prefix ofS1 where members ofS3 are beforeE inS, thenS3 +E isnot a prefix of any element sequence that is·locally valid· with respect toCT.

Then members ofS1 that form a·validation-path· inCT.{particle} (seeElement Sequence Locally Valid (Complex Content) (§3.4.4.3)) areattributed to the particles they match up with in the·validation-path·. Other members ofS1 areattributed to the{open content} ofCT. Members ofS2 arenotattributed to any component.

Note: The above definition makes sure that·attribution· happens even when the sequence of element information items is not·locally valid· with respect to aContent Type. For example, if a complex type definition has the following content model:

   <xs:sequence>     <xs:element name="a"/>     <xs:element name="b"/>     <xs:element name="c"/>   </xs:sequence>

and an input sequence

   <a/><b/><d/>

Then the element <a> is·attributed· to the particle whose term is the "a" element declaration. Similarly, is·attributed· to the "b" particle.

[Definition:] During·validation·, associations between element and attribute information items among the[children] and[attributes] on the one hand, and element and attribute declarations on the other, are also established. When an item is·attributed· to an·element particle·, then it is associated with the declaration which is the{term} of the particle. Similarly, when an attribute information item is·attributed to· anAttribute Use, then the item is associated with the{attribute declaration} of thatAttribute Use. Such declarations are called thecontext-determined declarations. See clause2.1 (inElement Locally Valid (Complex Type) (§3.4.4.2)) for attribute declarations, clause2 (inElement Sequence Locally Valid (Particle) (§3.9.4.2)) for element declarations.

3.4.5 Complex Type Definition Information Set Contributions

3.4.5.1 Attribute Default Value

Schema Information Set Contribution: Attribute Default Value

For each·defaulted attribute·,the·post-schema-validation infoset· has an attribute information item whoseproperties are as below added to the[attributes] of the elementinformation item.

In addition, if necessary·namespace fixup· is performed on the elementinformation item for the{attribute declaration}'s{target namespace}.

[local name]

The{attribute declaration}'s{name}.

[namespace name]

The{attribute declaration}'s{target namespace}.

[prefix]

If the{attribute declaration} has a·non-absent·{target namespace}N and the[in-scope namespaces] property bindsN to one or more prefixes, then a namespace prefix bound toN in the[in-scope namespaces] property of the element information item in the·post-schema-validation infoset·.

If more than one prefix is bound toN in the[in-scope namespaces], it is·implementation-dependent· which of those prefixes is used.

If the{attribute declaration} has a·non-absent·{target namespace}N and no prefix is bound toN in the[in-scope namespaces] property, then (as described in the discussion of·namespace fixup·) an·implementation-dependent· prefix.

Note: In this case (i.e. when·namespace fixup· is performed), the[in-scope namespaces] property is also augmented and an appropriate namespace attribute is added to the parent element's[namespace attributes].

If the{attribute declaration}'s{target namespace} is·absent·, then·absent·.

[normalized value]

The·effective value constraint·'s{lexical form}.

[owner element]

The element information item being assessed.

The·effective value constraint·'s{lexical form}.

[schema actual value]

The·effective value constraint·'s{value}.

[schema default]

The·effective value constraint·'s{lexical form}.

[validation context]

The nearest ancestor element information item with a[schema information] property.

[validity]

valid.

[validation attempted]

full.

[schema specified]

schema.

The added items also have[type definition](and[member type definition]and[member type definitions]if appropriate) properties, and their lighter-weight alternatives, as specified inAttribute Validated by Type (§3.2.5.4).

[Definition:] Whendefault values are supplied for attributes,namespace fixupmay be required, to ensure that the·post-schema-validation infoset· includes the namespace bindings needed and maintains the consistencyof the namespace information in the infoset. To performnamespace fixup on an element information itemE fora namespaceN:

1If the[in-scope namespaces] ofEbinds a prefix toN, nonamespace fixup is needed; the properties ofE are not changed.

2Otherwise, first select some prefixP which is not bound bythe[in-scope namespaces] ofE (the choice ofprefix is·implementation-dependent·).

3Add an entry to the[in-scope namespaces] ofE bindingP toN.

4Add a namespace attribute to the[namespace attributes] ofE.

5 Maintain the consistency of the information set by adjustingthe namespace bindings on the descendants ofE. This maybe done in either of two ways:

5.1Add the binding ofP toN to the[in-scope namespaces] of alldescendants ofE, except where that binding is overridden by another binding forP.

5.2Add to the[namespace attributes] of each child ofE a namespace attribute which undeclares the binding forP (i.e. anamespace attribute for prefixP whose·normalized value· is the empty string), unless that child already has anamespace declaration for prefixP.Note that this approach is possibleonly if[XML Namespaces 1.1] is in use,rather than[Namespaces in XML 1.0].

The choice between the two methods of maintainingconsistency in the information set is·implementation-dependent·.

If the·namespace fixup· is occasioned by a defaulted attribute with a non-absent target namespace, then (as noted above), the[prefix] of the attribute information item suppliedin the·post-schema-validation infoset· is set toP.

Note: When a default value of typeQName orNOTATION is applied, it is·implementation-dependent· whether·namespace fixup· occurs; if it does not, the prefix used in the lexical representation (in[normalized value] or[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.4.5.2 Match Information

Schema Information Set Contribution: Match Information

To allow users of the·post-schema-validation infoset· to distinguish element information items which are·attributed· to·element particles· from those·attributed· to·wildcard particles·, if and only if the local·validity· of an element information item has been assessed as defined byElement Locally Valid (Complex Type) (§3.4.4.2), then each attribute information item in its[attributes] has the following properties in the·post-schema-validation infoset·:

PSVI Contributions for attribute information items

[attribute attribution]: The appropriatecase among the following:
1Ifthe attribute information item is·attributed· to anAttribute Use,thenan·item isomorphic· to theAttribute Use.
2Ifthe attribute information item is·attributed· to an{attribute wildcard},thenan·item isomorphic· to the attribute wildcard.
3otherwise(the item is not·attributed· to anAttribute Use or an{attribute wildcard})·absent·.
[match information]: A keyword indicating what kind of component the attribute information item is·attributed· to. The appropriatecase among the following:
1Ifthe item is·attributed· to anAttribute Use,thenattribute
2Ifthe item is·attributed· to astrict{attribute wildcard},thenstrict
3Ifthe item is·attributed· to alax{attribute wildcard},thenlax
4Ifthe item is·attributed· to askip{attribute wildcard},thenskip
5otherwise(the item is not·attributed· to anAttribute Use or an{attribute wildcard})none

And each element information item in its[children] has the following properties in the·post-schema-validation infoset·:

PSVI Contributions for element information items

[element attribution]: The appropriatecase among the following:
1Ifthe element information item is·attributed· to an·element particle· or a·wildcard particle·,thenan·item isomorphic· to theParticle.
2Ifthe item is·attributed· to anOpen Content,thenan·item isomorphic· to theOpen Content.
3otherwise(the item is not·attributed· to aParticle or anOpen Content)·absent·.
[match information]: A keyword indicating what kind ofParticle the item is·attributed· to. The appropriatecase among the following:
1Ifthe item is·attributed· to an·element particle·,thenelement
2Ifthe item is·attributed· to astrict·wildcard particle·,thenstrict
3Ifthe item is·attributed· to alax·wildcard particle·,thenlax
4Ifthe item is·attributed· to askip·wildcard particle·,thenskip
5Ifthe item is·attributed· to anOpen Content,thenopen
6otherwise(the item is not·attributed· to aParticle or anOpen Content)none

3.4.6 Constraints on Complex Type Definition Schema Components

All complex type definitions (seeComplex Type Definitions (§3.4))must satisfy the following constraints.

3.4.6.1 Complex Type Definition Properties Correct

Schema Component Constraint: Complex Type Definition Properties Correct

All of the followingmust be true:

1The values of the properties of a complex type definition are as described inthe property tableau inThe Complex Type Definition Schema Component (§3.4.1), modulo the impact ofMissing Sub-components (§5.3).

2If the{base type definition} is a simple typedefinition, the{derivation method} isextension.

3There are no circular definitions, except for that of·xs:anyType·. That is, it is possible to reach the definition of·xs:anyType· by repeatedly following the{base type definition}.

4 No two distinct members of the{attribute uses} have{attribute declaration}s with the sameexpanded name.

5 If{content type}.{open content} is·non-absent·, then{content type}.{variety} is eitherelement-only ormixed.

3.4.6.2 Derivation Valid (Extension)

Schema Component Constraint: Derivation Valid (Extension)

For every complex typeT with{base type definition}B whereT.{derivation method} =extension,the appropriatecase among the followingmust be true:

1IfB is a complex type definition,thenall of the following are true:

1.1B.{final} does not containextension.

1.2B.{attribute uses} is a subset ofT.{attribute uses}. That is, for every attribute useU inB.{attribute uses}, there is an attribute use inT.{attribute uses} whose properties, recursively, are identical to those ofU.

1.3IfB has an{attribute wildcard}, thenT also has one, andB.{attribute wildcard}.{namespace constraint} is a subset ofT.{attribute wildcard}.{namespace constraint}, as defined byWildcard Subset (§3.10.6.2).

1.4One of the following is true:

1.4.1B andT both have{content type}.{variety} =simple and both have the same{content type}.{simple type definition}.

1.4.2B andT both have{content type}.{variety} =empty.

1.4.3All of the following are true:

1.4.3.1T.{content type}.{variety} =element-only ormixed.

1.4.3.2One of the following is true:

1.4.3.2.1B.{content type}.{variety} =empty.

1.4.3.2.2All of the following are true:

1.4.3.2.2.1BothB andT have{content type}.{variety} =mixed orboth have{content type}.{variety}=element-only.

1.4.3.2.2.2T.{content type}.{particle}is a·valid extension· ofB.{content type}.{particle}, as defined inParticle Valid (Extension) (§3.9.6.2).

1.4.3.2.2.3One or more of the following is true:

1.4.3.2.2.3.1B.{content type}.{open content} (call itBOT) is·absent·.

1.4.3.2.2.3.2T.{content type}.{open content} (call itEOT) has{mode}interleave.

1.4.3.2.2.3.3 BothBOT andEOT have{mode}suffix.

1.4.3.2.2.4 If neitherBOT norEOT is·absent·, thenBOT.{wildcard}.{namespace constraint}is a subset ofEOT.{wildcard}.{namespace constraint}, as definedbyWildcard Subset (§3.10.6.2).

1.5It is in principle possible to·derive·T in two steps, the first an extension and the second a restriction (possibly vacuous), from that type definition among its ancestors whose{base type definition} is·xs:anyType·.

Note: This requirement ensures that nothing removed by a restriction is subsequently added back by an extension in an incompatible way (for example,with a conflicting type assignment or valueconstraint).

Constructing the intermediate type definition to check this constraint is straightforward: simply re-order the·derivation· to put all the extension steps first, then collapse them into a single extension. If the resulting definition can be the basis for a valid restriction to the desired definition, the constraint is satisfied.

1.6 For any element or attribute information item, its·locally declared type· withinT is·validly substitutable· for the·locally declared type· withinB,·without limitation·, if neither is·absent·.

1.7B.{assertions} is a prefix ofT.{assertions}.

2IfB is a simple type definition,thenall of the following are true:

2.1T.{content type}.{variety} =simple andT.{content type}.{simple type definition} =B.

2.2B.{final} does not containextension.

[Definition:] A complex typeT is avalid extension of its{base type definition} if and only ifT.{derivation method} =extension andTsatisfies the constraintDerivation Valid (Extension) (§3.4.6.2).

3.4.6.3 Derivation Valid (Restriction, Complex)

Schema Component Constraint: Derivation Valid (Restriction, Complex)

For every complex typeT with{base type definition}B whereT.{derivation method} =restriction,all of the followingmust be true:

1B is a complex type definition whose{final} does not containrestriction.

2One or more of the following is true:

2.1B is·xs:anyType·.

2.2All of the following are true:

2.2.1T.{content type}.{variety} =simple

2.2.2One of the following is true:

2.2.2.1LetS_B beB.{content type}.{simple type definition}, andS_T beT.{content type}.{simple type definition}. ThenS_T is validly derived fromS_B as defined inType Derivation OK (Simple) (§3.16.6.3).

2.2.2.2B.{content type}.{variety} =mixed andB.{content type}.{particle} is aParticle which is·emptiable· as defined inParticle Emptiable (§3.9.6.3).

2.3All of the following are true:

2.3.1T.{content type}.{variety} =empty.

2.3.2One of the following is true:

2.3.2.1B.{content type}.{variety} =empty.

2.3.2.2B.{content type}.{variety} =element-only ormixed, andB.{content type}.{particle} is aParticle which is·emptiable· as defined inParticle Emptiable (§3.9.6.3).

2.4All of the following are true:

2.4.1One of the following is true:

2.4.1.1T.{content type}.{variety} =element-only andB.{content type}.{variety} =element-only ormixed.

2.4.1.2T andB both have{content type}.{variety} =mixed.

2.4.2The{content type} ofT·restricts· that ofB as defined inContent type restricts (Complex Content) (§3.4.6.4).

3For every element information itemE, if the[attributes] ofE satisfy clause2 and clause3 ofElement Locally Valid (Complex Type) (§3.4.4.2) with respect toT, then they also satisfy the same clauses with respect toB, and for every attribute information itemA inE.[attributes],B's·default binding· forA·subsumes· that defined byT.

4 For any element or attribute information item, its·locally declared type· withinT is·validly substitutable· for its·locally declared type· withinB, subject to the blocking keywords {extension,list,union}, if the item has a·locally declared type· both inT and inB.

5B.{assertions} is a prefix ofT.{assertions}.

[Definition:] A complex type definition with{derivation method} =restriction is avalid restriction of its{base type definition} if and only if the constraintDerivation Valid (Restriction, Complex) (§3.4.6.3) is satisfied.

Note: Validrestriction involves both a subset relation on the set ofelements valid againstT and those valid againstB, and a derivation relation, explicit in thetype hierarchy, between the types assigned to attributes andchild elements byT and those assigned to the sameattributes and children byB.

The constraint just given, like other constraints on schemas,must be satisfied by every complex typeT to which it applies.

However, under certain conditions conforming processors need not (although theymay) detect some violations of this constraint. If (1) the type definition being checked hasT .{content type} .{particle} .{term} .{compositor} =all and (2) an implementation is unable to determine by examination of the schema in isolation whether or not clause2.4.2 is satisfied, then the implementationmay provisionally accept the derivation. If any instance encountered in the·assessment· episode is valid againstT but not againstT.{base type definition}, then the derivation ofT does not satisfy this constraint, the schema does not conform to this specification, and no·assessment· can be performed using that schema.

It is·implementation-defined· whether a processor (a) always detects violations of clause2.4.2 by examination of the schema in isolation, (b) detects them only when some element information item in the input document is valid againstT but not againstT.{base type definition}, or (c) sometimes detects such violations by examination of the schema in isolation and sometimes not. In the latter case, the circumstances in which the processor does one or the other are·implementation-dependent·.

3.4.6.4 Content Type Restricts (Complex Content)

Schema Component Constraint: Content type restricts (Complex Content)

[Definition:] AContent TypeR (for "restriction") with complex content (i.e. one with a·non-absent·{particle})restricts anotherContent TypeB (for "base") with complex content if and only ifall of the following are true:

1Every sequence of element information items which is·locally valid· with respect toR is also·locally valid· with respect toB.

2For all sequences of element information itemsES which are·locally valid· with respect toR, for all elementsE inES,B's·default binding· forE·subsumes· that defined byR.

[Definition:] When a sequence of element information itemsES is·locally valid· with respect to aContent TypeCT or when a set of attribute information itemsAS satisfies clause2 and clause3 ofElement Locally Valid (Complex Type) (§3.4.4.2) with respect to aComplex Type Definition, there is a (partial) functional mapping from the element information itemsE in the sequenceES or the attribute information items inAS to adefault binding for the item, where the default binding is anElement Declaration, anAttribute Use, or one of the keywordsstrict,lax, orskip, as follows:

1When the item has a·governing element declaration·, the default binding is thatElement Declaration.

2 When the item has a·governing attribute declaration· and it is·attributed· to anAttribute Use, the default binding is thatAttribute Use.

3 When the item has a·governing attribute declaration· and it is·attributed· to an attribute wildcard, the default binding is anAttribute Use whose{attribute declaration} is the·governing attribute declaration·, whose{value constraint} is·absent·, and whose{inheritable} is the·governing attribute declaration·'s{inheritable} (the other properties in theAttribute Use are not relevant).

4When the item is·attributed· to astrict·wildcard particle· or attribute wildcard or anOpen Content with astrictWildcard and it does not have a·governing element declaration· or a·governing attribute declaration·, then the default binding is the keywordstrict.

5When the item is·attributed· to alax·wildcard particle· or attribute wildcard or anOpen Content with alaxWildcard and it does not have a·governing element declaration· or a·governing attribute declaration·, then the default binding is the keywordlax.

6When the item is·attributed· to askip·wildcard particle· or attribute wildcard or anOpen Content with askipWildcard then the default binding is the keywordskip.

[Definition:] A·default binding·G (for general)subsumes another·default binding·S (for specific) if and only ifone of the following is true

1G isskip.

2G islaxandS is notskip.

3BothG andS arestrict.

4G andS are both Element Declarations andall of the following are true:

4.1EitherG.{nillable} =true orS.{nillable} =false.

4.2EitherG has no{value constraint}, or it is notfixed, orS has afixed{value constraint} with an equal or identical value.

4.3S.{identity-constraint definitions} is a superset ofG.{identity-constraint definitions}.

4.4S disallows a superset of the substitutions thatG does.

4.5S's declared{type definition} is·validly substitutable as a restriction· forG's declared{type definition}.

4.6S.{type table} andG.{type table} either are both·absent· or are both·present· and·equivalent·.

5G andS are bothAttribute Uses andall of the following are true:

5.1S.{attribute declaration}.{type definition} is validly·derived· fromG.{attribute declaration}.{type definition}, as defined inType Derivation OK (Simple) (§3.16.6.3).

5.2 LetGVC beG's·effective value constraint· andSVC beS's·effective value constraint·, thenone or more of the following is true:

5.2.1GVC is·absent· or has{variety}default.

5.2.2SVC.{variety} =fixed andSVC.{value} is equal or identical toGVC.{value}.

5.3G.{inheritable} =S.{inheritable}.

Note: To restrict a complex type definition with a simple base type definitiontoempty, use a simple type definition with afixed value ofthe empty string: this preserves the type information.

Note: To restrict away a local element declaration that·competes· with a wildcard, use a wildcard in the derived type that explicitly disallows the element'sexpanded name. See the example given inXML Representation of Complex Type Definition Schema Components (§3.4.2).

3.4.6.5 Type Derivation OK (Complex)

The following constraint defines a relation appealed to elsewherein this specification.

Schema Component Constraint: Type Derivation OK (Complex)

For a complex type definition (call itD, for·derived·) to be validly·derived· from a type definition (call thisB, for base) subject to the blocking keywords ina subset of {extension,restriction}all of the followingmust be true:

1IfB andD are not the same typedefinition, then the{derivation method} ofD is notin the subset.

2One or more of the following is true:

2.1B =D.

2.2B =D.{base type definition}.

2.3All of the following are true:

2.3.1D.{base type definition} ≠·xs:anyType·.

2.3.2 The appropriatecase among the following is true:

2.3.2.1IfD.{base type definition} is complex,thenit is validly·derived· fromBsubject to the subset as defined by this constraint.

2.3.2.2IfD.{base type definition} is simple,thenit is validly·derived· fromBsubject to the subset as defined inType Derivation OK (Simple) (§3.16.6.3).

Note: This constraint is used to check that when someone uses a type in acontext where another type was expected (either viaxsi:type or·substitution groups·), that the type used is actually·derived· from the expectedtype, and that that·derivation· does not involve a form of·derivation· which wasruled out by the expected type.

Note: The wording of clause2.1 above appeals to a notion of component identity whichis only incompletely defined by this version of this specification.In some cases, the wording of this specification does make clear therules for component identity. These cases include:

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, whenthe two typedefinitions in question are the type definitions associated withtwo attribute or element declarations, which are discovered to be the samedeclaration);
When they are the same by construction (for example, when an element'stype definition defaults to being the same type definition as that of itssubstitution-group head or when a complex type definition inherits an attributedeclaration from its base type definition).

In other cases it is possiblethat conforming implementations willdisagree as to whether components are identical.

Note: When a complex type definitionS is said to be "validly·derived·" from a type definitionT,without mention of any specific set of blocking keywords,or with the explicit phrase "without limitation",then what is meant is thatS is validly derived fromT, subject to the empty set of blocking keywords,i.e. without any particular limitations.

3.4.7 Built-in Complex Type Definition

There is a complextype definition for·xs:anyType· present in every schemaby definition. It has the following properties:

Complex Type Definition of anyType

Property

Value

anyType

http://www.w3.org/2001/XMLSchema

itself

restriction

{content type}

AContent Type as follows:

Property

Value

mixed

aParticle with the properties shown below inOuter Particle for Content Type of anyType (§3.4.7).

{attribute uses}

The empty set

{attribute wildcard}

a wildcard with the following properties::

Property

Value

{prohibited substitutions}

ANamespace Constraint with the following properties:

Property

Value

any

The empty set

The empty set

lax

The empty set

The empty set

{assertions}

The empty sequence

{abstract}

false

The outer particle of·xs:anyType· contains a sequence with a single term:

Outer Particle for Content Type of anyType

Property

Value

Inner Particle for Content Type of anyType

a model group withthe following properties:

Property

Value

{compositor}

sequence

{particles}

a list containing one particle with the properties shown below inInner Particle for Content Type of anyType (§3.4.7).

The inner particle of·xs:anyType· contains a wildcard which matches any element:

Property

Value

unbounded

a wildcard with the following properties:

Property

Value

ANamespace Constraint with the following properties:

Property

Value

any

The empty set

The empty set

lax

Note: This specification does not provide an inventory of built-in complextype definitions for use in user schemas. A preliminary library of complex typedefinitions is available which includes both mathematical (e.g.rational) and utility (e.g.array) type definitions. In particular, there is atext type definition which is recommended for useas the type definition in element declarations intended for general textcontent, as it makes sensible provision for various aspects ofinternationalization. For more details, see the schema document for the typelibrary at its namespace name:http://www.w3.org/2001/03/XMLSchema/TypeLibrary.xsd.

3.5 Attribute Uses

        3.5.1The Attribute Use Schema Component
        3.5.2XML Representation of Attribute Use Schema Components
        3.5.3Constraints on XML Representations of Attribute Uses
        3.5.4Attribute Use Validation Rules
        3.5.5Attribute Use Information Set Contributions
        3.5.6Constraints on Attribute Use Schema Components

An attribute use is a utility component which controls the occurrence anddefaulting behavior of attribute declarations. It plays the same role forattribute 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 ofthe possibilities for controlling occurrence.

3.5.1 The Attribute Use Schema Component

The attribute use schema component has the following properties:

Schema Component:Attribute Use, a kind ofAnnotated Component

{annotations}

A sequence ofAnnotation components.

{required}

An xs:boolean value. Required.

{attribute declaration}

AnAttribute Declaration component. Required.

{value constraint}

AValue Constraint property record. Optional.

{inheritable}

An xs:boolean value. Required.

Property Record:Value Constraint

{variety}

One of {default,fixed}. Required.

{value}

An·actual value·. Required.

{lexical form}

A character string. Required.

{required} determines whether this use of an attributedeclaration requires an appropriate attribute information item to be present, ormerely allows it.

{attribute declaration} provides the attribute declaration itself,which will in turn determine the simple type definition used.

{value constraint} allows for local specification of a default or fixed value. Thismust be consistent with that of the{attribute declaration}, in that if the{attribute declaration} specifies a fixed value, the only allowed{value constraint} is the same fixed value, or a value equal or identical to it.

SeeAnnotations (§3.15) for information on the role of the{annotations} property.

3.5.2 XML Representation of Attribute Use Schema Components

Attribute uses correspond to all uses of<attribute> whichallow ause attribute. These in turn correspond totwo components in each case, an attribute use and its{attribute declaration} (although note the latter is not new when the attribute use is a reference to a top-level attribute declaration). The appropriate mapping is described inXML Representation of Attribute Declaration Schema Components (§3.2.2).

3.5.3 Constraints on XML Representations of Attribute Uses

None as such.

3.5.4 Attribute Use Validation Rules

[Definition:] Theeffective value constraint of an attribute useU isU.{value constraint}, if present, otherwiseU.{attribute declaration}.{value constraint}, if present, otherwise theeffective value constraint is·absent·.

Validation Rule: Attribute Locally Valid (Use)

For an attribute information item to be·valid· with respect to an attribute use its·actual value·must be equal or identical to the{value} of the attribute use's{value constraint}, if it is present and has{variety}fixed.

3.5.5 Attribute Use Information Set Contributions

None as such.

3.5.6 Constraints on Attribute Use Schema Components

All attribute uses (seeAttribute Uses (§3.5))must satisfy the following constraints.

Schema Component Constraint: Attribute Use Correct

All of the followingmust be true:

1The values of the properties of an attribute useU are as described in the property tableau inThe Attribute Use Schema Component (§3.5.1), modulo the impact ofMissing Sub-components (§5.3).

2IfU.{value constraint} is not·absent·, then it is a valid default with respect toU.{attribute declaration}.{type definition} as defined inSimple Default Valid (§3.2.6.2).

3IfU.{attribute declaration} has{value constraint}.{variety} =fixed andU itself has a{value constraint}, thenU.{value constraint}.{variety} =fixed andU.{value constraint}.{value} is identical toU.{attribute declaration}.{value constraint}.{value}.

3.6 Attribute Group Definitions

        3.6.1The Attribute Group Definition Schema Component
        3.6.2XML Representation of Attribute Group Definition Schema Components
            3.6.2.1XML Mapping Rule for Named Attribute Groups
            3.6.2.2Common Rules for Attribute Wildcards
        3.6.3Constraints on XML Representations of Attribute Group Definitions
        3.6.4Attribute Group Definition Validation Rules
        3.6.5Attribute Group Definition Information SetContributions
        3.6.6Constraints on Attribute Group Definition Schema Components

A schema can name a group of attribute declarations so that they can be incorporated as agroup into complex type definitions.

Attribute group definitions do not participate in·validation· as such, but the{attribute uses} and{attribute wildcard}of one ormore complex type definitionsmay be constructed in whole or part by referenceto an attribute group. Thus, attribute group definitions provide areplacement for some uses of XML'sparameter entity facility.Attribute group definitions are provided primarily for reference from the XMLrepresentation of schema components(see<complexType> and<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 attributedeclarations in the group were present in the type definition.

The example above illustrates the pattern mentioned inXML Representations of Components (§3.1.2): The same element, in this caseattributeGroup, serves both to define and to incorporate by reference. In the firstattributeGroup element in the example, thename attribute is required and theref attribute is forbidden; in the second theref attribute is required, thename attribute is forbidden.

3.6.1 The Attribute Group Definition Schema Component

The attribute group definition schema component has thefollowing properties:

Schema Component:Attribute Group Definition, a kind ofAnnotated Component

{annotations}

A sequence ofAnnotation components.

{name}

An xs:NCName value. Required.

{target namespace}

An xs:anyURI value. Optional.

{attribute uses}

A set ofAttribute Use components.

{attribute wildcard}

AWildcard component. Optional.

Attribute groups are identified by their{name} and{target namespace}; attribute group identitiesmust be unique within an·XSD schema·. SeeReferences to schema components across namespaces (<import>) (§4.2.6) for the use of componentidentifiers when importing one schema into another.

{attribute uses} is a set ofattribute uses, allowingfor local specification of occurrence and default or fixed values.

{attribute wildcard} provides for an attribute wildcard to be included in anattribute group.See above underComplex Type Definitions (§3.4) for theinterpretation ofattribute wildcards during·validation·.

SeeAnnotations (§3.15) for information on the role of the{annotations} property.

3.6.2 XML Representation of Attribute Group Definition Schema Components

3.6.2.1 XML Mapping Rule for Named Attribute Groups

The XML representation for an attribute group definition schema component is an<attributeGroup> element information item. It provides for naming a group of attribute declarations and an attribute wildcard for use by reference in the XML representation of complex type definitions and other attribute group definitions. The correspondences between the properties of the information item after the appropriate·pre-processing· and the properties of the component it corresponds to are given in this section.

XML Representation Summary:attributeGroup Element Information Item

<attributeGroup
 id =ID
 name =NCName
 ref =QName
 {any attributes with non-schema namespace . . .}>
 Content:(annotation?, ((attribute |attributeGroup)*,anyAttribute?))
</attributeGroup>

When an<attributeGroup> appears as a child of<schema> or<redefine>, it corresponds to an attribute group definition as below. When it appears as a child of<complexType> or<attributeGroup>, it does not correspond to any component as such.

Note: If the<attributeGroup> is a child of<override>, and it overrides a corresponding declaration in the·target set· of its parent, it will also correspond to an attribute group definition as shown below. SeeOverriding component definitions (<override>) (§4.2.5) for details.

XML Mapping Summary forAttribute Group DefinitionSchema Component

Property

Representation

The·actual value· of thename[attribute]

The·actual value· of thetargetNamespace[attribute] of the<schema> ancestor element information item if present, otherwise·absent·.

{attribute uses}

The union of the set of attribute uses corresponding to the<attribute>[children], if any, with the{attribute uses} of the attribute groups·resolved· to by the·actual value·s of theref[attribute] of the<attributeGroup>[children], if any.

Note: As described below, circular references from<attributeGroup> to<attributeGroup> are not errors.

{attribute wildcard}

TheWildcard determined by applying the attribute-wildcard mapping described inCommon Rules for Attribute Wildcards (§3.6.2.2) to the<attributeGroup> element information item.

The·annotation mapping· of the<attributeGroup> element and its<attributeGroup>[children], if present, as defined inXML Representation of Annotation Schema Components (§3.15.2).

Note: It is a consequence of this rule and the rule inXML Representation of Complex Type Definition Schema Components (§3.4.2)that any annotations specified in attribute group references are included inthe sequence ofAnnotations of the enclosingComplex Type Definition orAttribute Group Definition components.

The rules given above for{attribute uses} and{attribute wildcard} specify that if an<attributeGroup> elementA contains a reference to another attribute groupB (i.e.A's[children] include an<attributeGroup> with aref attribute pointing atB), thenA maps to anAttribute Group Definition component whose{attribute uses} reflect not only the<attribute>[children] ofA but also those ofB and of any<attributeGroup> elements referred to inB. The same is true for attribute groups referred to from complex types.

Circular reference isnot disallowed. That is, it is not an error ifB, or some<attributeGroup> element referred to byB (directly, or indirectly at some remove) contains a reference toA. An<attributeGroup> element involved in such a reference cycle maps to a component whose{attribute uses} and{attribute wildcard} properties reflect all the<attribute> and<any> elements contained in, or referred to (directly or indirectly) by elements in the cycle.

Note: In version 1.0 of this specification, circular group reference was notallowed except in the[children] of<redefine>. As described above, this version allows it.The effect is to take the transitive closure of the reference relation between<attributeGroup> elements and take into accountall their{attribute uses} and{attribute wildcard} properties.

3.6.2.2 Common Rules for Attribute Wildcards

The following mapping for attribute-wildcards forms part of the XML mapping rules for different kinds of source declaration (most prominently<attributeGroup>). It can be applied to any element which can have an<anyAttribute> element as a child, and produces as a result either aWildcard or the special value·absent·. The mapping depends on the concept of the·local wildcard·:

[Definition:] Thelocal wildcard of an element information itemEis the appropriatecase among the following:

1IfE has an<anyAttribute> child,thentheWildcard mapped to by the<anyAttribute> element using the wildcard mapping set out inXML Representation of Wildcard Schema Components (§3.10.2);

2otherwise·absent·.

The mapping is defined as follows:

1 LetL be the·local wildcard·

2LetW be a sequence containing all the·non-absent·{attribute wildcard}s of the attribute groups referenced byE, in document order.

3 The value is then determined by the appropriatecase among the following:

3.1IfW is empty,thenthe·local wildcard·L.

3.2otherwisethe appropriatecase among the following:

3.2.1IfL is·non-absent·,thena wildcard whose properties are as follows:

Property

Value

{process contents}

L.{process contents}

L.{annotations}

the wildcard intersection ofL.{namespace constraint} and of the{namespace constraint}s of all the the wildcards inW, as defined inAttribute Wildcard Intersection (§3.10.6.4)

3.2.2otherwise(no<anyAttribute> ispresent)a wildcard whose properties are as follows:

Property

Value

{process contents}

The{process contents} of the first wildcard inW

The wildcard intersection of the{namespace constraint}s of all the wildcards inW, as defined inAttribute Wildcard Intersection (§3.10.6.4)

·The empty sequence·

3.6.3 Constraints on XML Representations of Attribute Group Definitions

Schema Representation Constraint: Attribute Group Definition Representation OK

None as such.

3.6.4 Attribute Group Definition Validation Rules

None as such.

3.6.5 Attribute Group Definition Information SetContributions

None as such.

3.6.6 Constraints on Attribute Group Definition Schema Components

All attribute group definitions (seeAttribute Group Definitions (§3.6))must satisfy the following constraint.

Schema Component Constraint: Attribute Group Definition Properties Correct

All of the followingmust be true:

1The values of the properties of an attribute group definitionare as described in the property tableau inThe Attribute Group Definition Schema Component (§3.6.1), modulo the impactofMissing Sub-components (§5.3);

2No two distinct members of the{attribute uses} have{attribute declaration}s with the sameexpanded name.

3.7 Model Group Definitions

        3.7.1The Model Group Definition Schema Component
        3.7.2XML Representation of Model Group Definition Schema Components
        3.7.3Constraints on XML Representations of Model Group Definitions
        3.7.4Model Group Definition Validation Rules
        3.7.5Model Group Definition Information Set Contributions
        3.7.6Constraints on Model Group Definition Schema Components

A model group definition associates a name and optional annotations with aModel Group.By reference to the name, the entire model group can be incorporated by reference into a{term}.

Model group definitions are providedprimarily for reference from theXML Representation of Complex Type Definition Schema Components (§3.4.2) (see<complexType>and<group>). Thus, model group definitions provide areplacement for some uses of XML'sparameter entity facility.

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 wholecontent model, then as one alternative in a choice.

3.7.1 The Model Group Definition Schema Component

The model group definition schema component has the followingproperties:

Schema Component:Model Group Definition, a kind ofAnnotated Component

{annotations}

A sequence ofAnnotation components.

{name}

An xs:NCName value. Required.

{target namespace}

An xs:anyURI value. Optional.

{model group}

AModel Group component. Required.

Model group definitions are identified by their{name} and{target namespace}; model group identitiesmust be unique within an·XSD schema·. SeeReferences to schema components across namespaces (<import>) (§4.2.6) for the use of componentidentifiers when importing one schema into another.

Model group definitionsper se do not participate in·validation·, but the{term} ofa particlemay correspond in whole or in partto a model group from a model group definition.

{model group} is theModel Group for which the model group definition provides a name.

SeeAnnotations (§3.15) for information on the role of the{annotations} property.

3.7.2 XML Representation of Model Group Definition Schema Components

The XML representation for a model group definition schema component is a<group> element information item.It provides fornaming a model group for use by reference in the XML representation ofcomplex type definitions and model groups. The correspondences between theproperties of the information item after the appropriate·pre-processing·and theproperties of the component it corresponds to are given in this section.

XML Representation Summary:group Element Information Item

<group
 id =ID
 maxOccurs = (nonNegativeInteger |unbounded) : 1
 minOccurs =nonNegativeInteger : 1
 name =NCName
 ref =QName
 {any attributes with non-schema namespace . . .}>
 Content:(annotation?, (all |choice |sequence)?)
</group>

If the item has<schema> or<redefine> as its parent (in which case there will be aname[attribute], then the item maps to a model group definition component with properties as follows:

Note: If the item is a child of<override>, it will also have aname[attribute]; if it overrides a corresponding declaration in the·target set· of its parent, it will also (in the overridden schema document) map to a component as described below. SeeOverriding component definitions (<override>) (§4.2.5) for details.

XML Mapping Summary forModel Group DefinitionSchema Component

Property

Representation

The·actual value· of thename[attribute]

The·actual value· ofthetargetNamespace[attribute] of the<schema> ancestor element informationitem if present, otherwise·absent·.

{model group}

A model group which isthe{term} of a particlecorresponding to the<all>,<choice> or<sequence> among the[children] (theremustbe exactly one).

The·annotation mapping· of the<group> element, as defined inXML Representation of Annotation Schema Components (§3.15.2).

Otherwise, if the item has aref[attribute] and doesnot haveminOccurs=maxOccurs=0 , then the<group> element maps to a particle component with properties as follows:

XML Mapping Summary forParticleSchema Component

Property

Representation

The·actual value· of theminOccurs[attribute], if present, otherwise1.

unbounded, if themaxOccurs[attribute] equalsunbounded, otherwise the·actual value· of themaxOccurs[attribute], if present, otherwise1.

The{model group} of the model group definition·resolved· to by the·actual value· of theref[attribute]

The·annotation mapping· of the<group> element, as defined inXML Representation of Annotation Schema Components (§3.15.2).

Otherwise, the<group> hasminOccurs=maxOccurs=0, in which case it maps to no component at all.

Note: The name of this section is slightly misleading, in that the second, un-named, case above (with aref and noname) is not really a named model group at all, but a reference to one. Also note that in the first (named) case above no reference is made tominOccurs ormaxOccurs: this is because the schema for schema documents does not allow them on the child of<group> when it is named. This in turn is because the{min occurs} and{max occurs} of the particles whichrefer to the definition are what count.

3.7.3 Constraints on XML Representations of Model Group Definitions

None as such.

3.7.4 Model Group Definition Validation Rules

None as such.

3.7.5 Model Group Definition Information Set Contributions

None as such.

3.7.6 Constraints on Model Group Definition Schema Components

All model group definitions (seeModel Group Definitions (§3.7))must satisfy the following constraint.

Schema Component Constraint: Model Group Definition Properties Correct

The values of the properties of a model group definitionmust be as described inthe property tableau inThe Model Group Definition Schema Component (§3.7.1), modulo the impact ofMissing Sub-components (§5.3).

3.8 Model Groups

        3.8.1The Model Group Schema Component
        3.8.2XML Representation of Model Group Schema Components
        3.8.3Constraints on XML Representations of Model Groups
        3.8.4Model Group Validation Rules
            3.8.4.1Language Recognition by Groups
            3.8.4.2Principles of Validation against Groups
            3.8.4.3Element Sequence Valid
        3.8.5Model Group Information Set Contributions
        3.8.6Constraints on Model Group Schema Components
            3.8.6.1Model Group Correct
            3.8.6.2All Group Limited
            3.8.6.3Element Declarations Consistent
            3.8.6.4Unique Particle Attribution
            3.8.6.5Effective Total Range (all and sequence)
            3.8.6.6Effective Total Range (choice)

When the[children] of element information items are not constrainedto beempty or by reference to a simple type definition(Simple Type Definitions (§3.16)), the sequence of elementinformation item[children] contentmay be specified inmore detail with a model group. Because the{term} property of a particle can be amodel group, and model groups contain particles, model groups can indirectly contain other model groups; the grammar for model groupsis therefore recursive.[Definition:] A model groupdirectly contains the particles in the value of its{particles} property.[Definition:] A model groupindirectly contains the particles, groups, wildcards, andelement declarations which are·contained· by the particles it·directly contains·.[Definition:] A model groupcontains the components which it either·directly contains·or·indirectly 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 nestedinside the second.

3.8.1 The Model Group Schema Component

The model group schema component has the followingproperties:

Schema Component:Model Group, a kind ofTerm

{annotations}

A sequence ofAnnotation components.

{compositor}

One of {all,choice,sequence}. Required.

{particles}

A sequence ofParticle components.

specifies a sequential (sequence),disjunctive (choice) or conjunctive (all) interpretation ofthe{particles}. This in turn determines whether the elementinformation item[children]·validated· by the model groupmust:

(sequence) correspond, in order, to the specified{particles};
(choice) correspond to exactly one of the specified{particles};
(all) correspond to the specified{particles}. The elements can occur in anyorder.

When two or more element declarations contained·directly·,·indirectly·, or·implicitly· in the{particles} of a model group have identical names, the type definitions of those declarationsmust be thesame.

SeeAnnotations (§3.15) for information on the role of the{annotations} property.

3.8.2 XML Representation of Model Group Schema Components

The XML representation for a model group schema component iseither an<all>, a<choice> or a<sequence>element information item. The correspondences between theproperties of those information itemsafter the appropriate·pre-processing·and theproperties of the component they correspond to are given in this section.

XML Representation Summary:all Element Information Item et al.

<all
 id =ID
 maxOccurs = (0 |1) : 1
 minOccurs = (0 |1) : 1
 {any attributes with non-schema namespace . . .}>
 Content:(annotation?, (element |any |group)*)
</all>

<choice
 id =ID
 maxOccurs = (nonNegativeInteger |unbounded) : 1
 minOccurs =nonNegativeInteger : 1
 {any attributes with non-schema namespace . . .}>
 Content:(annotation?, (element |group |choice |sequence |any)*)
</choice>

<sequence
 id =ID
 maxOccurs = (nonNegativeInteger |unbounded) : 1
 minOccurs =nonNegativeInteger : 1
 {any attributes with non-schema namespace . . .}>
 Content:(annotation?, (element |group |choice |sequence |any)*)
</sequence>

Each of the above items corresponds to a particle containing a model group, with properties as follows (unlessminOccurs=maxOccurs=0, in which case the item corresponds to no component at all):

XML Mapping Summary forParticleSchema Component

Property

Representation

The·actual value· of theminOccurs[attribute], if present, otherwise1.

unbounded, if themaxOccurs[attribute] equalsunbounded, otherwise the·actual value· of themaxOccurs[attribute], if present, otherwise1.

A model group as given below.

The same annotations as the{annotations} ofthe model group. See below.

The particle just described has aModel Group as the value of its{term} property, as follows.

XML Mapping Summary forModel GroupSchema Component

Property

Representation

{compositor}

One ofall,choice,sequence depending on the elementinformation item.

{particles}

A sequence of particlescorresponding to all the<all>,<choice>,<sequence>,<any>,<group> or<element> items amongthe[children], in order.

The·annotation mapping· of the<all>,<choice>, or<sequence> element, whichever is present, as defined inXML Representation of Annotation Schema Components (§3.15.2).

3.8.3 Constraints on XML Representations of Model Groups

None as such.

3.8.4 Model Group Validation Rules

In order to define the validation rules for modelgroups clearly, it will be useful to define some basic terminology;this is done in the next two sections, before the validation rulesthemselves are formulated.

3.8.4.1 Language Recognition by Groups

Each model groupM denotes a languageL(M), whose members are the sequences of element information items·accepted· byM.

WithinL(M) a smaller languageV(M) can beidentified, which is of particular importance for schema-validityassessment. The difference between the two languages is thatV(M) enforces some constraints which are ignored in the definitionofL(M).InformallyL(M) is the set of sequences which are accepted by a modelgroup if no account is taken of the schema componentconstraintUnique Particle Attribution (§3.8.6.4) or the related provisions in the validation rules which specify how to choose a unique·path· in a non-deterministic model group. By contrast,V(M) takesaccount of those constraints and includes only the sequences which are·locally valid· againstM. For all model groupsM,V(M) is asubset ofL(M).L(M) and related concepts are described in thissection;V(M) is described in the next section,Principles of Validation against Groups (§3.8.4.2).

[Definition:] When a sequenceS of element informationitems is checked against a model groupM, the sequence of·basic particles· which the items ofS match, in order, is apath ofS inM. For a givenS andM, thepath ofS inM is not necessarily unique.Detailed rules for the matching, and thus for the construction ofpaths, are given inLanguage Recognition by Groups (§3.8.4.1) andPrinciples of Validation against Particles (§3.9.4.1).Not every sequence has a path in every model group, but everysequence accepted by the model group does have a path.[Definition:] Fora model groupM and a sequenceS inL(M), the pathofS inM is acomplete path; prefixes ofcomplete paths which are themselves not complete pathsareincomplete paths. For example, in the model group

   <xs:sequence>    <xs:element name="a"/>    <xs:element name="b"/>    <xs:element name="c"/>   </xs:sequence>

the sequences (<a/><c/>)and (<a/>) have·paths·(the first a·complete path· and the secondan·incomplete path·),but the sequences (<a/><c/><d/>) and(<a/><x/>) do not have paths.

Note: It is possible, but unusual, for a model group tohave some paths which are neither complete paths, norprefixes of complete paths. For example, the model group

   <xs:sequence>    <xs:element name="a"/>    <xs:element name="b"/>    <xs:choice/>   </xs:sequence>

accepts no sequences because the emptychoice recognizesno input sequences. But the sequences (<a/>)and (<a/>) have paths in the model group.

The definitions ofL(M) and·paths· inM, whenM is a·basic term· ora·basic particle·, are given inPrinciples of Validation against Particles (§3.9.4.1). The definitions for groups aregiven below.

3.8.4.1.1 Sequences

This section definesL(M), the set of·paths· inM, andV(M), ifMis a sequence group.

IfM is aModel Group,and the{compositor} ofM issequence, and the{particles} ofM is the sequenceP₁,P₂, ...,P_n, thenL(M) is the set of sequencesS =S₁ +S₂ + ... +Sn (taking "+" as the concatenation operator), whereS_i is inL(P_i) for 0 <i ≤n.The sequence of sequencesS₁,S₂, ...,Sn is a·partition· ofS.Less formally, whenM is a sequence ofP₁,P₂, ...P_n, thenL(M) is the set of sequences formed by taking one sequence which isaccepted byP₁, then one accepted byP₂, and so on, up throughP_n, and then concatenating them together in order.

[Definition:] Apartition of a sequence is a sequence of sub-sequences,some or all of whichmay be empty, such that concatenating allthe sub-sequences yields the original sequence.

WhenM is a sequence groupandS is a sequence of input items, the set of·paths· ofS inM is the set of allpathsQ =Q₁ +Q₂ + ... +Q_j, where

j ≤n, and
S =S₁ +S₂ + ... +S_j (i.e.S₁,S₂, ...,S_j isa·partition· ofS), and
S_i is inL(P_i) for 0 <i <j, and
Q_i is a·path· ofS_i inP_i for 0 <i ≤j.

Example

By this definition, some sequences which do not satisfy theentire model group nevertheless have·paths· in a model group.For example, given the model groupM

   <xs:sequence>    <xs:element name="a"/>    <xs:element name="b"/>    <xs:element name="c"/>   </xs:sequence>

and an input sequenceS

<a/><b/>

wheren = 3,j = 2, thenS₁ is (<a/>),S₂ is (),andS has a·path· inM, even thoughS is not inL(M). The·path· has two items, first theParticlefor thea element, then theParticle for theb element.

WhenM is a sequence group,the setV(M) (the set of sequences·locally valid· againstM) is the set of sequencesS whichare inL(M) and which have a·validation-path· inM.Informally,V(M) contains those sequences which areaccepted byM and for which no element information itemis ever·attributed to· a·wildcard particle· if it can, incontext, instead be·attributed to· an·element particle·.There will invariably be a·partition· ofS whosemembers are·locally valid· against{particles}ofM.

Note: For sequences with more than one·path· inM,the·attributions· ofthe·validation-path· are used in validation and for determiningthe contents of the·post-schema-validation infoset·. For example, ifM is

  <xs:sequence>   <xs:any minOccurs="0"/>   <xs:element name="a" minOccurs="0"/>  </xs:sequence>

then the sequence (<a/>) has two·paths·inM, one containing just the·wildcard particle· and the othercontaining just the·element particle·. It is the latterwhich is a·validation-path· and which determines whichParticle the item in the input is·attributed to·.

Note: There are model groups for which some members ofL(M) are not inV(M). For example, ifM is

  <xs:sequence>   <xs:any minOccurs="0"/>   <xs:element name="a"/>  </xs:sequence>

then the sequence (<a/><a/>) is inL(M), but notinV(M), because the validation rules require that the firsta be·attributed to· the·wildcard particle·.In a·validation-path· the initiala will invariably be·attributed to· the·element particle·, and so no sequencewith an initiala can be·locally valid· againstthis model group.

3.8.4.1.2 Choices

This section definesL(M), the set of·paths· inM, andV(M), ifMis a choice group.

When the{compositor} ofM ischoice, and the{particles} ofM is the sequenceP₁,P₂, ...,P_n,thenL(M) isL(P₁) ∪L(P₂) ∪ ... ∪L(P_n),and the set of·paths· ofS inP is the setQ =Q₁ ∪Q₂ ∪ ... ∪Q_n, whereQ_i is the set of·paths· ofS inP_i, for0 <i ≤n.Less formally, whenM is a choice ofP₁,P₂, ...P_n, thenL(M) contains any sequence accepted by any of the particlesP₁,P₂, ...P_n,and any·path· ofS in any of the particlesP₁,P₂, ...P_nis a·path· ofS inP.

The setV(M) (the set of sequences·locally valid· againstM) is the set of sequencesS whichare inL(M) and which have a·validation-path· inM.In effect, this means that if one of the choices inM·attributes· an initial element information item toa·wildcard particle·, and another·attributes· the sameitem to an·element particle·, then the latter choice is usedfor validation.

Note: For example, ifM is

  <xs:choice>   <xs:any/>   <xs:element name="a"/>  </xs:choice>

then the·validation-path· for the sequence (<a/>)contains just the·element particle· and it is to the·element particle· that the input element will be·attributed·; the alternate·path·containing just the·wildcard particle· is not relevant forvalidation as defined in this specification.

3.8.4.1.3 All-groups

This section definesL(M), the set of·paths· inM, andV(M), ifMis an all-group.

When the{compositor} ofM isall, and the{particles} ofM is the sequenceP₁,P₂, ...,P_n,thenL(M) is the set of sequencesS =S₁ ×S₂ × ... ×Sn(taking "×" as the interleave operator),wherefor 0 <i ≤n,S_i is inL(P_i).The set of sequences{S₁,S₂, ...,Sn} is a·grouping· ofS.The set of·paths· ofS inP isthe set of all·paths·Q =Q₁ ×Q₂ × ... ×Q_n,whereQ_i is a·path· ofS_i inP_i, for 0 <i ≤n.

Less formally, whenM is anall-group ofP₁,P₂, ...P_n, thenL(M) is the set of sequences formed by taking one sequence whichis accepted byP₁, then one accepted byP₂,and so on, up throughP_n, and then interleaving themtogether. Equivalently,L(M) is the set of sequencesSsuch that the set {S₁,S₂, ...,Sn} is a·grouping· ofS, and for 0 <i ≤n,S_i is inL(P_i).

[Definition:] Agrouping of a sequence is a set of sub-sequences, some orall of which may be empty, such that each member of the originalsequence appears once and only once in one of the sub-sequences andall members of all sub-sequences are in the originalsequence.

For example, given the model groupM

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

and an input sequenceS

<a/><b/><a/>

wheren = 3, thenS₁ is (<a/><a/>),S₂ is (),and the·path· ofS inM is the sequence containing first theParticlefor thea element, then theParticle for theb element, then once more theParticle for thea element.

The setV(M) (the set of sequences·locally valid· againstM) is the set of sequencesS whichare inL(M) and which have a·validation-path· inM.In effect, this means that if one of theParticles inM·attributes· an element information item toa·wildcard particle·, and a·competing·Particle ·attributes· the same item to an·element particle·, then the·element particle· is used for validation.

Note: For example, ifM is

  <xs:all>   <xs:any/>   <xs:element name="a"/>  </xs:all>

thenM accepts sequences of length two, containingonea element and one other element.

The other element can be anything at all, including a seconda element. After the firstathe·element particle· accepts no more elementsand so no longer·competes· with the·wildcard particle·.So if the sequence (<a/><a/>)is checked againstM, in the·validation-path· thefirsta element will be·attributed to·the·element particle· and the second to the·wildcard particle·.

If the intention is not to allow the seconda,use a wildcard that explicitly disallows it. That is,

  <xs:all>   <xs:any notQName="a"/>   <xs:element name="a"/>  </xs:all>

Now the sequence (<a/><a/>) is notaccepted by the particle.

3.8.4.1.4 Multiple Paths in Groups

It is possible for a given sequence of element information itemsto have multiple·paths· in a given model groupM; this isthe case, for example, whenM is ambiguous, as for example

  <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/>)in more than one way.It may also be the case with unambiguous model groups, ifthey do not correspond to adeterministicexpression (as it is termed in[XML 1.1])or a "1-unambiguous" expression, as itis defined by[Brüggemann-Klein / Wood 1998].For example,

  <xs:sequence>   <xs:element name="a" minOccurs="0"/>   <xs:element name="a"/>  </xs:sequence>

Note: Because these model groups do not obey theconstraintUnique Particle Attribution (§3.8.6.4), they cannotappear in a conforming schema.

3.8.4.2 Principles of Validation against Groups

As noted above, each model groupM denotes alanguageL(M), whose members are sequences of element informationitems. Each member ofL(M) has one or more·paths· inM, as doother sequences of element information items.

By imposing conditions on·paths· in a model groupMit is possible to identify a set of·validation-paths· inM,such that ifM is a model group which obeys theUnique Particle Attribution (§3.8.6.4) constraint, then any sequenceS has at most one·validation-path· inM.The languageV(M) can then be defined as the set ofsequences which have·validation-paths· inM.

[Definition:] TwoParticlesP₁ andP₂ contained in someParticlePcompete with each other if and only if some sequenceSof element information items has two·paths· inP which areidentical except that one path hasP₁ as its last item and the otherhasP₂.

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/>) has two paths,one (Q₁) consisting of theParticle whose{term} isthe declaration fora followed by theParticle whose{term} isthe declaration forb, anda second (Q₂) consisting of theParticle whose{term} isthe declaration fora followed by theParticle whose{term} isthe wildcard. The sequencesQ₁ andQ₂ are identical except for their last items, and so thetwoParticles which are the last items ofQ₁ andQ₂ are said to·compete· with each other.

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>

theParticles forb and the wildcard do not·compete·, because there is nopair of·paths· inP which differ only in one having the·element particle· forb andthe other having the·wildcard particle·.

[Definition:] Two(or more)·paths· of a sequenceS in aParticleParecompeting paths if and only ifthey are identical except for their final items, which differ.

[Definition:] For any sequenceS of elementinformation items and any particleP, a·path· ofS inPis avalidation-path if and only if for eachprefix of the·path· which ends with a·wildcard particle·, thecorresponding prefix ofS has no·competing path· whichends with an·element particle·.

Note: It is a consequence of the definition of·validation-path· that forany content modelM which obeys constraintUnique Particle Attribution (§3.8.6.4) and for any sequenceS ofelement information items,S has at most one·validation-path· inM.

[Definition:] A sequenceS ofelement information items islocally valid againsta particleP if and only ifS has a·validation-path· inP. The set of all such sequences is writtenV(P).

3.8.4.3 Element Sequence Valid

Validation Rule: Element Sequence Valid

For a sequenceS (possibly empty) of element information items to belocally·valid· with respect toa model groupM,Smust be inV(M).

Note: It is possible to define groups whose{particles} is empty. When achoice-groupM has an empty{particles} property, thenL(M) is the empty set.WhenM is asequence- orall-group with an empty{particles} property, thenL(M) is the set containing the empty (zero-length) sequence.

3.8.5 Model Group Information Set Contributions

None as such.

3.8.6 Constraints on Model Group Schema Components

All model groups (seeModel Groups (§3.8))must satisfy the following constraints.

3.8.6.1 Model Group Correct

Schema Component Constraint: Model Group Correct

All of the followingmust be true:

1The values of the properties of a model group are as described in the property tableau inThe Model Group Schema Component (§3.8.1), modulo the impact ofMissing Sub-components (§5.3).

2There are no circular groups. That is, within the{particles} of a group there is no particle at any depth whose{term} is the group itself.

3.8.6.2 All Group Limited

Schema Component Constraint: All Group Limited

When a model group has{compositor}all, thenall of the followingmust be true:

1It appears only as the value of one or more of the following properties:

1.1the{model group} property of a model group definition.

1.2the{term} property of aParticle with{max occurs} = 1 which is the{particle} of the{content type} of a complex type definition.

1.3the{term} property of aParticleP with{min occurs}={max occurs}= 1, whereP is among the{particles} of aModel Group whose{compositor} isall.

2For every particleP in its{particles}, ifP.{term} is a model group, thenP.{term}.{compositor} =all.

3.8.6.3 Element Declarations Consistent

Schema Component Constraint: Element Declarations Consistent

If the{particles} property contains, eitherdirectly, indirectly (that is, within the{particles} property of acontained model group, recursively), or·implicitly·, two or more elementdeclarations with the sameexpanded name, then all their typedefinitionsmust be the same top-level definition, that is,all of the followingmust be true:

1All their declared{type definition}s have a·non-absent·{name}.

2All theirdeclared{type definition}s have the same{name}.

3All theirdeclared{type definition}s have the same{target namespace}.

4All their{type table}s are eitherall·absent· or else all are present and·equivalent·.

Ifall of the following are true:

1 The{particles} property contains (either directly, indirectly, or·implicitly·) one or more element declarations with the sameexpanded nameQ;call these element declarationsEDS.

2 At leastone of the following is true

2.1 The{particles} property contains one or morestrict orlax·wildcard particles· which·match·Q.

2.2 TheModel Group is the{term} of the·content model· of someComplex Type DefinitionCTD andCTD.{content type} has an{open content} with astrict orlaxWildcard which·matches·Q.

3 There exists a top-level element declarationG with theexpanded nameQ.

then the{type table}s ofEDSand the{type table} ofGmust eitherall be·absent· or else all be present and·equivalent·.

[Definition:] A listof particlesimplicitly contains an element declaration if and only if amember of the list contains thatelement declaration in its·substitution group·.

[Definition:] AType TableT1 isequivalent to aType TableT2 if and only ifall of the following are true:

1T1.{alternatives} has the same length asT2.{alternatives} and their corresponding entries are·equivalent·.

2T1.{default type definition} andT2.{default type definition} are·equivalent·.

[Definition:] AnyType Alternative isequivalent to itself.Otherwise, anyType AlternativeT1 isequivalent to a differentType AlternativeT2 if and only ifT1.{test} andT2.{test} are true for the sameset of input element information itemsandT1.{type definition} andT2.{type definition} acceptthe same set of input information items as valid.In the general case, equivalence and non-equivalencecan be difficult to establish.It is·implementation-defined· under just what conditions aprocessor detects that two typealternatives are equivalent, but allprocessorsmust detectT1 andT2 asequivalent ifall of the following are true:

1T1.{test}.{namespace bindings} andT2.{test}.{namespace bindings} have the same number ofNamespace Bindings, and for each entry inT1.{test}.{namespace bindings} there is a corresponding entry inT2.{test}.{namespace bindings} with the same{prefix} and{namespace}.

2T1.{test}.{default namespace} andT2.{test}.{default namespace} either are both·absent· or have the same value.

3T1.{test}.{base URI} andT2.{test}.{base URI} either are both·absent· or have the same value.

4T1.{test}.{expression} andT2.{test}.{expression} have the same value.

5T1.{type definition} andT2.{type definition} are the same type definition.

A processormay treat two type alternatives as non-equivalent if they do not satisfy the conditions justgiven and the processor does not detect that theyare nonetheless equivalent.

Note: In the general case, equivalence can be difficult to prove, so the minimum required of implementations is kept relatively simple. Schema authors can avoid interoperability issues by ensuring that any type alternatives for which equivalence must be established do satisfy the tests above. Implementationsmay recognize cases when differences of namespace bindings, base URIs, and white space in the XPath expression do not affect the meaning of the expression.

3.8.6.4 Unique Particle Attribution

[Definition:] Anelement particle is aParticle whose{term} is anElement Declaration.[Definition:] Awildcard particle is aParticle whose{term} is aWildcard.Wildcard particles may bereferred to as "strict", "lax",or "skip" particles, depending on the{process contents} propertyof their{term}.

Schema Component Constraint: Unique Particle Attribution

A content modelmust not contain two·element particles· which·compete· with each other, nor two·wildcard particles· which·compete· with each other.

Note: Content models in which an·element particle· and a·wildcard particle··compete· with each other arenot prohibited.In such cases, theElement Declaration is chosen; see the definitions of·attribution·and·validation-path·.

Note: This constraint reconstructs for XSD the equivalentconstraints of[XML 1.1] and SGML. SeeAnalysis of the Unique Particle Attribution Constraint (non-normative) (§J) for furtherdiscussion.

Since this constraint is expressed at the component level, itapplies to content models whose origins (e.g. via type·derivation· andreferences to named model groups) are no longer evident. So particles atdifferent points in the content model are always distinct from one another,even if they originated from the same named model group.

Note: It is a consequence ofUnique Particle Attribution (§3.8.6.4), together withthe definition of·validation-path·, that any sequenceS of elementinformation items has at most one·validation-path· in any particleP.This means in turn that each item inS is attributed to at most one particle inP.No item can match more than oneWildcardor more than oneElement Declaration (because no two·wildcard particles·and no two·element particles·may·compete·), and if an item matchesboth a·wildcard particle· and an·element particle·, it is·attributed· bythe rules for·validation-paths· to the·element particle·.

Note: Because locally-scoped element declarations sometimeshave and sometimes do not have a{target namespace}, the scope ofdeclarations isnot relevant to enforcing either theUnique Particle Attribution (§3.8.6.4) constraint or theElement Declarations Consistent (§3.8.6.3) constraint.

3.8.6.5 Effective Total Range (all andsequence)

The following constraints define relations appealed to elsewhere in this specification.

Schema Component Constraint: Effective Total Range (all andsequence)

The effective total range of a particlePwhose{term} is a groupGwhose{compositor} isall orsequence is a pair of minimum and maximum, as follows:

minimum

The product ofP.{min occurs} and the sum of the{min occurs} of every wildcard or element declaration particle inG.{particles} and the minimum part of the effective total range of each of the group particles inG.{particles} (or0 if there are no{particles}).

maximum

unbounded if the{max occurs} of any wildcard or element declaration particle inG.{particles} or the maximum part of the effective total range of any of the group particles inG.{particles} isunbounded, or if any of those is non-zero andP.{max occurs} =unbounded, otherwise the product ofP.{max occurs} and the sum of the{max occurs} of every wildcard or element declaration particle inG.{particles} and the maximum part of the effective total range of each of the group particles inG.{particles} (or0 if there are no{particles}).

3.8.6.6 Effective Total Range (choice)

Schema Component Constraint: Effective Total Range (choice)

The effective total range of a particlePwhose{term} is a groupGwhose{compositor} ischoice is a pair of minimum and maximum, as follows:

minimum

The product ofP.{min occurs} and the minimum of the{min occurs} of every wildcard or element declaration particle inG.{particles} and the minimum part of the effective total range of each of the group particles inG.{particles} (or0 if there are no{particles}).

maximum

unbounded if the{max occurs} of any wildcard or element declaration particle inG.{particles} or the maximum part of the effective total range of any of the group particles inG.{particles} isunbounded, or if any of those is non-zero andP.{max occurs} =unbounded, otherwise the product ofP.{max occurs} and the maximum of the{max occurs} of every wildcard or element declaration particle inG.{particles} and the maximum part of the effective total range of each of the group particles inG.{particles} (or0 if there are no{particles}).

3.9 Particles

        3.9.1The Particle Schema Component
        3.9.2XML Representation of Particle Schema Components
        3.9.3Constraints on XML Representations of Particles
        3.9.4Particle Validation Rules
            3.9.4.1Principles of Validation against Particles
            3.9.4.2Element Sequence Locally Valid (Particle)
            3.9.4.3Element Sequence Accepted (Particle)
        3.9.5Particle Information Set Contributions
        3.9.6Constraints on Particle Schema Components
            3.9.6.1Particle Correct
            3.9.6.2Particle Valid (Extension)
            3.9.6.3Particle Emptiable

As described inModel Groups (§3.8), particles contribute to the definitionof content models.

When an element is validated against a complex type, its sequence of child elements is checked against the content model ofthe complex type and the children are·attributed to· toParticles of the content model.The attribution of items toParticlesdetermines the calculation of the items'·context-determined declarations·and thus partially determines the·governingelement declarations· for the children:when an element information item is·attributed to· an·element particle·, thatParticle'sElement Declaration,or anElement Declaration ·substitutable· for it,becomesthe item's·context-determined declaration· andthus normally its·governing element declaration·; when the item is·attributed to· a·wildcard particle·, the·governing element declaration· depends on the{process contents} property of the wildcard andonQName 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 ofthe possibilities for controlling occurrence.

3.9.1 The Particle Schema Component

The particle schema component has the following properties:

Schema Component:Particle, a kind ofComponent

{min occurs}

An xs:nonNegativeInteger value. Required.

{max occurs}

Either a positive integer orunbounded. Required.

{term}

ATerm component. Required.

{annotations}

A sequence ofAnnotation components.

In general, multiple elementinformation item[children], possibly with intervening character[children] if the content typeismixed, can be·validated· withrespect to a single particle. When the{term} is an elementdeclaration or wildcard,{min occurs} determines the minimum number of such element[children] that can occur. The number of such childrenmust be greater than or equal to{min occurs}. If{min occurs} is0, then occurrence of such children is optional.

Again, when the{term} is an elementdeclaration or wildcard, the number of such element[children]must be less than or equal to any numeric specification of{max occurs}; if{max occurs} isunbounded, then there is noupper bound on the number of such children.

When the{term} is a model group, the permittedoccurrence range is determined by a combination of{min occurs} and{max occurs} and the occurrence ranges of the{term}'s{particles}.

[Definition:] A particledirectly contains the component which is the value of its{term} property.[Definition:] A particleindirectly contains the particles, groups, wildcards, andelement declarations which are contained by the value of its{term} property.[Definition:] A particlecontains the components which it either·directly contains·or·indirectly contains·.

SeeAnnotations (§3.15) for information on the role of the{annotations} property.

3.9.2 XML Representation of Particle Schema Components

Particles in the schema typically correspond to element information items that can bearminOccurs andmaxOccurs attributes in the schema document:

Local<element>, seeXML Representation of Element Declaration Schema Components (§3.3.2)
Model groups<all>,<sequence>, and<choice>, seeXML Representation of Model Group Schema Components (§3.8.2)
Group references<group>, seeXML Representation of Model Group Definition Schema Components (§3.7.2)
Wildcard<any>, seeXML Representation of Wildcard Schema Components (§3.10.2)

Sometimes particles do not correspond to any of these elements. For example, particles may be synthesized in complex type extension.

3.9.3 Constraints on XML Representations of Particles

None as such.

3.9.4 Particle Validation Rules

3.9.4.1 Principles of Validation against Particles

Every particleP·recognizes· some languageL(P).When{min occurs} and{max occurs} ofP areboth 1,L(P) is the language ofP's{term},as described inValidation of Basic Terms (§3.9.4.1.2). Thefollowing section (Language Recognition for Repetitions (§3.9.4.1.1))describes how more complicated counts are handled.

3.9.4.1.1 Language Recognition for Repetitions

WhenP.{min occurs} =P.{max occurs} =n, andP.{term} =T, thenL(P) is the set of sequencesS =S₁ +S₂ + ... +Sn such thatS_i is inL(T) for 0 <i ≤n.Less formally:L(P) is theset of sequences which have·partitions· inton sub-sequencesfor which each of then subsequences is in the language accepted by the{term} ofP.

WhenP.{min occurs} =j andP.{max occurs} =k,andP.{term} =T, thenL(P) is the set of sequencesS =S₁, +S₂ + ... +Sn, i.e. theset of sequences which have·partitions· inton sub-sequencessuch thatn ≥j andn ≤k (ork isunbounded)andS_i is inL(T) for 0 <i ≤n.

WhenP.{min occurs} = 0, thenL(P) also includes the empty sequence.

If (1)ParticleP has{min occurs} =j,{max occurs} =k, and{term} =T, and (2)S is a sequence of element information itemssuch thatS =S₁ +S₂ + ... +Sn (i.e.S₁,S₂, ...,Sn isa·partition· ofS), and (3)n ≤k (ork isunbounded), and (4)S_i is inL(T) for 0 <i <n, then:

IfT is a model group, then the set of·paths· ofS inP is the set of all·paths·Q such thatQ =Q₁ +Q₂ + ... +Q_n, whereQ_i is a·path· ofS_i inT for 0 <i ≤n.(For the definition of·paths· in model groups,seeLanguage Recognition by Groups (§3.8.4.1).)
IfT is a·basic term·, then the (sole)·path· ofS inPis a sequence ofn occurrences ofP.

Note: Informally: the path of an input sequenceS in a particleP may go through the·basic particles· inP as many times as is allowed byP.{max occurs}.If the path goes throughP more than once, eachtime before the last one must correspond to a sequenceaccepted byP.{term}; because the last iteration in the pathmay not be complete, it need not be accepted by the{term}.

3.9.4.1.2 Validation of Basic Terms

In the preceding section (Language Recognition for Repetitions (§3.9.4.1.1)), the languageL(P)·accepted· by aParticleP is defined in terms of the language·accepted· byP's{term}. This section definesL(T) for·basic terms·;for the definition ofL(T) whenT is a group, seeLanguage Recognition by Groups (§3.8.4.1).

[Definition:] For anyElement DeclarationD, the languageL(D)·accepted· byD is the set of all sequences oflength 1 whose sole member is an element information item which·matches·D.

[Definition:] An element information itemEmatches anElement DeclarationD if and only ifone of the following is true:

1E andD have the sameexpanded name,

2Theexpanded name ofE·resolves· to an elementdeclarationD₂ which is·substitutable·forD.

[Definition:] Anexpanded nameEmatches an·NCName·N anda namespace nameNS (or, equivalently,N andNSmatchE)if and only if all of the followingare true:

The local name ofE is identical toN.
Either the namespace name ofE is identical toNS,or elseE has no namespace name (E is an unqualifiedname) andNS is·absent·.

Note: For convenience,expanded namesare sometimes spoken of as·matching·aType Definition, anElement Declaration, anAttribute Declaration,or other schema component which has both a{name}and a{target namespace} property (or vice versa,the component is spoken of as·matching·theexpanded name), when what is meantis, strictly speaking, that theexpanded name ·matches· the{name}and{target namespace} properties of the component.

[Definition:] For anyWildcardW, the languageL(W)·accepted· byWis the set of all sequences oflength 1 whose sole member is an element information item which·matches·W.

[Definition:] An element information itemEmatches aWildcardW (or a·wildcard particle· whose{term} isW)if and only ifEis locally·valid· with respect toW, as defined in the validation ruleItem Valid (Wildcard) (§3.10.4.1).

[Definition:] Two namespacenamesN₁ andN₂ are said tomatch if and only if they are identical or both are·absent·.

For principles of validation when the{term} is a model groupinstead of a·basic particle·, seeLanguage Recognition by Groups (§3.8.4.1) andPrinciples of Validation against Groups (§3.8.4.2).

3.9.4.2 Element Sequence Locally Valid (Particle)

Validation Rule: Element Sequence Locally Valid (Particle)

For a sequence (possibly empty) of element information items to belocally·valid· with respect to aParticleall of the followingmust be true:

1The sequence must be accepted by theParticle, as definedinElement Sequence Accepted (Particle) (§3.9.4.3).

3.9.4.3 Element Sequence Accepted (Particle)

Validation Rule: Element Sequence Accepted (Particle)

For a sequence (possibly empty) of element information items to beaccepted by aParticleP,

the appropriatecase among the followingmust be true:

1IfP.{term} is a wildcard,thenall of the following are true:

1.1The length of the sequence is greater than or equal toP.{min occurs}.

1.2IfP.{max occurs} is a number, then the length of the sequence is less than or equal to the{max occurs}.

1.3Each element information item in the sequence is·valid· with respect to the wildcard as defined byItem Valid (Wildcard) (§3.10.4.1).

In this case, each element information item in the sequence is·attributed to·P and has no·context-determined declaration·.

2IfP.{term} is an element declarationD,thenall of the following are true:

2.1The length of the sequence is greater than or equal toP.{min occurs}.

2.2IfP.{max occurs} is a number, then the length of the sequence is less than or equal to the{max occurs}.

2.3 For each element information itemE in the sequenceone or more of the following is true:

2.3.1D has the sameexpanded name asE.

In this caseD is the·context-determined declaration·forE with respect toSchema-Validity Assessment (Element) (§3.3.4.6) andAssessment Outcome (Element) (§3.3.5.1).

2.3.2D is top-level (i.e.D.{scope}.{variety} =global), its{disallowed substitutions} does not containsubstitution,E'sexpanded name ·resolves· to an element declarationS —[Definition:] call this declaration thesubstituting declaration — and·S· is·substitutable· forD as defined inSubstitution Group OK (Transitive) (§3.3.6.3).

In this case·S· is the·context-determined declaration·forE with respect toSchema-Validity Assessment (Element) (§3.3.4.6) andAssessment Outcome (Element) (§3.3.5.1).

In this caseE is·attributed to·P.

Note: This clause is equivalent to requiring that the sequence of length 1 containingE is in·L(D)·.

3IfP.{term} is a model group,thenall of the following are true:

3.1There is a·partition· of the sequence inton sub-sequences such thatn is greater than or equal toP.{min occurs}.

3.2IfP.{max occurs} is a number,n is less than or equal toP.{max occurs}.

3.3Each sub-sequence in the·partition· is·valid· with respect to that model group as defined inElement Sequence Valid (§3.8.4.3).

In this case, the element information items in each sub-sequence are·attributed to·Particles within the model group which is the{term}, as described inLanguage Recognition by Groups (§3.8.4.1).

Note: The rule just given does not require that thecontent model be deterministic. In practice, however, most non-determinism in content models is ruled out by the schemacomponent constraintUnique Particle Attribution (§3.8.6.4).Non-determinism can occur despite that constraint forseveral reasons.In some such cases, some particular element information item may be accepted by either aWildcard or anElement Declaration. In such situations,the validation process defined in this specification matches theelement information item against theElement Declaration, both inidentifying theElement Declaration as the item's·context-determined declaration·, and in choosing alternative paths through a content model.Other cases of non-determinism involve nested particles each ofwhich has{max occurs} greater than 1,where the input sequence can be partitioned in multiple ways.In those cases, there is no fixed rule for eliminating thenon-determinism.

Note: clause1 and clause2.3.2 do notinteract: an element information item validatable by a declarationwith a substitution group head isnot validatable by a wildcard which accepts the head's(namespace, name) pair but not its own.

3.9.5 Particle Information Set Contributions

None as such.

3.9.6 Constraints on Particle Schema Components

3.9.6.1 Particle Correct

All particles (seeParticles (§3.9))must satisfy the following constraint.

Schema Component Constraint: Particle Correct

All of the followingmust be true:

1The values of the properties of a particle are as described inthe property tableau inThe Particle Schema Component (§3.9.1), modulo the impact ofMissing Sub-components (§5.3).

2 If{max occurs} is notunbounded, that is, it has anumeric value, thenall of the following are true:

2.1{min occurs} is not greater than{max occurs}.

3.9.6.2 Particle Valid (Extension)

The following constraint defines a relation appealed to elsewhere in this specification.

Schema Component Constraint: Particle Valid (Extension)

[Definition:] For a particle(call itE, for extension) to be avalid extension ofanother particle (call itB, for base)one or more of the following is true:

1They are the same particle.

2E.{min occurs} =E.{max occurs} = 1 andE.{term} is asequence group whose{particles}' first member is a particle all of whose properties, recursively, are identical to those ofB.

3All of the following are true:

3.1E.{min occurs} =B.{min occurs}.

3.2 BothE andB haveall groups as their{term}s.

3.3The{particles} ofB'sall group is a prefix of the{particles} ofE'sall group.

3.9.6.3 Particle Emptiable

The following constraint defines a relation appealed to elsewhere in this specification.

Schema Component Constraint: Particle Emptiable

[Definition:] For a particle to beemptiableone or more of the following is true:

1Its{min occurs} is0.

2Its{term} is a group and the minimum part of theeffective total range of that group, as defined byEffective Total Range (all andsequence) (§3.8.6.5) (ifthe group isall orsequence) orEffective Total Range (choice) (§3.8.6.6) (if it ischoice), is0.

3.10 Wildcards

3.10.1The Wildcard Schema Component
 3.10.2XML Representation of Wildcard Schema Components
 3.10.2.1Mapping from <any> to a Particle
 3.10.2.2Mapping from <any> and <anyAttribute> to a Wildcard Component
 3.10.3Constraints on XML Representations of Wildcards
 3.10.4Wildcard Validation Rules
 3.10.4.1Item Valid (Wildcard)
 3.10.4.2Wildcard allows Expanded Name
 3.10.4.3Wildcard allows Namespace Name
 3.10.5Wildcard Information Set Contributions
 3.10.6Constraints on Wildcard Schema Components
 3.10.6.1Wildcard Properties Correct
 3.10.6.2Wildcard Subset
 3.10.6.3Attribute Wildcard Union
 3.10.6.4Attribute Wildcard Intersection

In order to exploit the full potential for extensibility offered by XMLplus namespaces, more provision is needed than DTDs allow for targeted flexibility in contentmodels and attribute declarations. A wildcard provides for·validation· ofattribute and element information items dependent on their namespacenamesand optionally on their local names.

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"/><xs:any notNamespace="##targetNamespace ##local"/><xs:anyAttribute namespace="http://www.w3.org/XML/1998/namespace"/>

XML representations of the four basic types of wildcard, plus one attribute wildcard.

3.10.1 The Wildcard Schema Component

The wildcard schema component has the following properties:

Schema Component:Wildcard, a kind ofTerm

{annotations}

A sequence ofAnnotation components.

{namespace constraint}

ANamespace Constraint property record. Required.

{process contents}

One of {skip,strict,lax}. Required.

Property Record:Namespace Constraint

{variety}

One of {any,enumeration,not}. Required.

{namespaces}

A set each of whose members is either an xs:anyURI value or the distinguished value·absent·. Required.

{disallowed names}

A set each of whose members is either an xs:QName value or the keyworddefined or the keywordsibling. Required.

{namespace constraint} provides for·validation· of attribute and element items that:

({variety}any) have any namespace or are not namespace-qualified;
({variety}not and{namespaces} a set whose members are either namespace names or·absent·) have any namespace other than the specified namespaces and/or, if·absent· is included in the set, are namespace-qualified; (see thisexample, which accepts only namespace-qualified names distinct from the target namespace; the "##local" in the schema document maps to the value·absent· in the{namespace constraint} property)
({variety}enumeration and{namespaces} a set whose members are either namespace names or·absent·) have any of the specified namespaces and/or, if·absent· is included in the set, are unqualified.
({disallowed names} containsQName members) have anyexpanded name other than the specified names.
({disallowed names} contains the keyworddefined) have anyexpanded name other than those matching the names of global element or attribute declarations.
({disallowed names} contains the keywordsibling) have anyexpanded name other than those matching the names of element or attribute declarations in the containing complex type definition.

{process contents} controls the impact on·assessment·of the information items allowed by wildcards, as follows:

strict

Theremust be a top-level declaration for the itemavailable, or the itemmust have anxsi:type, and theitemmust be·valid· asappropriate.

skip

No constraints at all: the itemmust simply be well-formed XML.

lax

If the item has a uniquelydetermined declaration available, itmust be·valid· with respect tothat declaration, that is,·validate·if you can, don't worry if you can't.

SeeAnnotations (§3.15) for information on the role of the{annotations} property.

3.10.2 XML Representation of Wildcard Schema Components

The XML representation for a wildcard schema component is an<any> or<anyAttribute> element information item.

XML Representation Summary:any Element Information Item

<any
 id =ID
 maxOccurs = (nonNegativeInteger |unbounded) : 1
 minOccurs =nonNegativeInteger : 1
 namespace = ((##any |##other) | List of (anyURI | (##targetNamespace |##local)) )
 notNamespace = List of (anyURI | (##targetNamespace |##local))
 notQName = List of (QName | (##defined |##definedSibling))
 processContents = (lax |skip |strict) : strict
 {any attributes with non-schema namespace . . .}>
 Content:(annotation?)
</any>

XML Representation Summary:anyAttribute Element Information Item

<anyAttribute
 id =ID
 namespace = ((##any |##other) | List of (anyURI | (##targetNamespace |##local)) )
 notNamespace = List of (anyURI | (##targetNamespace |##local))
 notQName = List of (QName |##defined)
 processContents = (lax |skip |strict) : strict
 {any attributes with non-schema namespace . . .}>
 Content:(annotation?)
</anyAttribute>

An<any> information item corresponds both to a wildcard component and to a particle containing that wildcard (unlessminOccurs=maxOccurs=0, in which case the item corresponds to no component at all). The mapping rules are given in the following two subsections. As always, the mapping rules given here apply after, not before, the appropriate·pre-processing·.

Processorsmay issue a warning if a list ofxs:anyURI values in thenamespace ornoNamespace attributes includes any values beginning with the string '##'.

Note: Strings beginning with '##' are not IRIs or URIS according to the definitions given in the relevant RFCs (for references see[XML Schema: Datatypes]) and users of this specification are discouraged from using them as namespace names, to avoid confusion with the keyword values defined by this specification.

3.10.2.1 Mapping from <any> to a Particle

The mapping from an<any> information item to a particle is as follows.

XML Mapping Summary forParticleSchema Component

Property

Representation

The·actual value· of theminOccurs[attribute], if present, otherwise1.

unbounded, ifmaxOccurs =unbounded, otherwise the·actual value· of themaxOccurs[attribute], if present, otherwise1.

A wildcard as givenbelow.

The same annotations as the{annotations} of the wildcard. See below.

3.10.2.2 Mapping from <any> and <anyAttribute> to a Wildcard Component

The mapping from an<any> information item to a wildcard component is as follows. This mapping is also used for mapping<anyAttribute> information items to wildcards, although in some cases the result of the mapping is further modified, as specified in the rules for<attributeGroup> and<complexType>.

XML Mapping Summary forWildcardSchema Component

Property

Representation

ANamespace Constraint with the following properties:

Property

Value

the appropriatecase among the following:

1Ifthenamespace[attribute] is present,then the appropriatecase among the following:

1.1Ifnamespace ="##any",thenany;

1.2Ifnamespace ="##other",thennot;

1.3otherwiseenumeration;

2IfthenotNamespace[attribute] is present,thennot;

3otherwise(neithernamespace nornotNamespace is present)any.

{namespaces}

the appropriatecase among the following:

1Ifneithernamespace nornotNamespace is present,thenthe empty set;

2Ifnamespace ="##any",thenthe empty set;

3Ifnamespace ="##other",thena set consisting of·absent· and, if thetargetNamespace [attribute] of the<schema> ancestor element information item is present, its·actual value·;

4otherwisea set whose members are namespace names corresponding to the space-delimited substrings of the·actual value· of thenamespace ornotNamespace[attribute] (whichever is present), except

4.1if one such substring is##targetNamespace, the correspondingmember is the·actual value· of thetargetNamespace[attribute] of the<schema> ancestorelement information item if present, otherwise·absent·;

4.2if one such substring is##local, thecorresponding member is·absent·.

{disallowed names}

If thenotQName[attribute] is present, then a set whose members correspond to the items in the·actual value· of thenotQName[attribute], as follows.

If the item is aQName value (i.e. anexpanded name), then thatQName value is a member of the set.
If the item is the token "##defined", then the keyworddefined is a member of the set.
If the item is the token "##definedSibling", then the keywordsibling is a member of the set.

If thenotQName[attribute] is not present, then the empty set.

{process contents}

The·actual value· of theprocessContents[attribute], if present,otherwisestrict.

The·annotation mapping· of the<any> element, as defined inXML Representation of Annotation Schema Components (§3.15.2).

Note: When this rule is used for an attribute wildcard (seeXML Representation of Complex Type Definition Schema Components (§3.4.2)), the{annotations} is the·annotation mapping· of the<anyAttribute> element.

Wildcards are subject to the same ambiguity constraints (Unique Particle Attribution (§3.8.6.4)) as other content model particles: If an instance element could match one of two wildcards, within the content model of a type, that model is in error.

3.10.3 Constraints on XML Representations of Wildcards

Schema Representation Constraint: Wildcard Representation OK

In addition to the conditions imposed on<any> and<anyAttribute> element information items by the schema for schema documents,namespace andnotNamespace attributesmust not both bepresent.

3.10.4 Wildcard Validation Rules

3.10.4.1 Item Valid (Wildcard)

Validation Rule: Item Valid (Wildcard)

For an element or attribute information itemI to be locally·valid· with respect to a wildcardWall of the followingmust be true:

1Theexpanded name ofI is·valid· with respect toW.{namespace constraint}, as defined inWildcard allows Expanded Name (§3.10.4.2).

2IfW.{namespace constraint}.{disallowed names} contains the keyworddefined,thenboth of the following are true:

2.1IfW is an element wildcard (i.e.,W appears in a content model),thentheexpanded name ofI does not·resolve· to an element declaration. (Informally, no such top-level element is declared in the schema.)

2.2IfW is an attribute wildcard,thentheexpanded name ofI does not·resolve· to an attribute declaration.

3Ifall of the following are true:

3.1W.{namespace constraint}.{disallowed names} contains the keywordsibling;

3.2W is an element wildcard

3.3I is an element information item

3.4I has a[parent]P that is also an element information item

3.5I andP have the same[validation context]

3.6P has an·governing type definition·T (which is always a complex type and containsW in its·content model·)

thentheexpanded name ofI does not·match· any element declaration·contained· in the content model ofT, whether·directly·,·indirectly·, or·implicitly·.

Informally, the keywordsibling disallows any element declared as a possible sibling of the wildcardW.

When an element or attribute informationitem is·attributed· to a wildcard and the preceding constraint(Item Valid (Wildcard) (§3.10.4.1)) is satisfied, then the item has no·context-determined declaration·. Its·governing· declaration, if any, is found by matching itsexpanded name as described inQName resolution (Instance) (§3.17.6.3).Note that QName resolution is performed only if the item is·attributed· toastrict orlax wildcard; if the wildcard has a{process contents} property ofskip, then the item has no·governing· declaration.

[Definition:] An element or attribute information item isskipped if it is·attributed· to askip wildcard or if one of its ancestor elements is.

3.10.4.2 Wildcard allows Expanded Name

Validation Rule: Wildcard allows Expanded Name

For anexpanded nameE, i.e. a(namespace name, local name) pair, to be·valid· with respect to a namespace constraintCall of the followingmust be true:

1The namespace name is·valid· with respect toC, as defined inWildcard allows Namespace Name (§3.10.4.3);

2C.{disallowed names} does not containE.

3.10.4.3 Wildcard allows Namespace Name

Validation Rule: Wildcard allows Namespace Name

For a valueV which is either a namespace name or·absent· to be·valid· with respect to a namespace constraintC(thevalue of a{namespace constraint})one of the followingmust be true:

1C.{variety} =any.

2C.{variety} =not, andV is not identical to any of the members ofC.{namespaces}.

3C.{variety} =enumeration, andV is identical to one of the members ofC.{namespaces}.

3.10.5 Wildcard Information Set Contributions

None as such.

3.10.6 Constraints on Wildcard Schema Components

3.10.6.1 Wildcard Properties Correct

All wildcards (seeWildcards (§3.10))must satisfy the following constraint.

Schema Component Constraint: Wildcard Properties Correct

All of the followingmust be true:

1The values of the properties of a wildcard are as described in the property tableau inThe Wildcard Schema Component (§3.10.1), modulo the impact ofMissing Sub-components (§5.3).

2If{variety} isnot,{namespaces} has at least one member.

3If{variety} isany,{namespaces} is empty.

4The namespace name of eachQName member in{disallowed names} is allowed by the{namespace constraint}, as defined inWildcard allows Namespace Name (§3.10.4.3).

5Attribute wildcards do not containsibling in their{namespace constraint}.{disallowed names}.

3.10.6.2 Wildcard Subset

The following constraints define a relation appealed to elsewhere in this specification.

Schema Component Constraint: Wildcard Subset

[Definition:] Given twoNamespace Constraintssub andsuper,sub is awildcard subset ofsuper if and only ifone of the following is true

1super.{variety} =any.

2Bothsub andsuper have{variety} =enumeration, andsuper.{namespaces} is a superset ofsub.{namespaces}.

3sub.{variety} =enumeration,super.{variety} =not, and the{namespaces} of the two are disjoint.

4Bothsub andsuper have{variety} =not, andsuper.{namespaces} is a subset ofsub.{namespaces}.

Andall of the following are true:

1EachQName member ofsuper.{disallowed names} is not allowed bysub, as defined inWildcard allows Expanded Name (§3.10.4.2).

2 Ifsuper.{disallowed names} containsdefined, thensub.{disallowed names} also containsdefined.

3 Ifsuper.{disallowed names} containssibling, thensub's{disallowed names} also containssibling.

3.10.6.3 Attribute Wildcard Union

Schema Component Constraint: Attribute Wildcard Union

[Definition:] Given threeNamespace ConstraintsO,O1, andO2,O is thewildcard union ofO1 andO2 if and only if, first, the{variety} and{namespaces}, and, second, the{disallowed names} ofO are consistent withO being the union ofO1 andO2, as that is defined below.

The{variety} and{namespaces} ofO are consistentwithO being the wildcard union ofO1 andO2 if andonly ifone or more of the following is true:

1O,O1, andO2 all have the same{variety} and{namespaces}.

2EitherO1.{variety} =any orO2.{variety} =any, andO.{variety} =any.

3O,O1, andO2 all have{variety}enumeration, andO.{namespaces} is the union ofO1.{namespaces} andO2.{namespaces}.

4O1.{variety} =O2.{variety} =not, andone of the following is true

4.1 The intersection of the{namespaces} ofO1 andO2 is the empty set, andO.{variety} =any.

4.2O.{variety} =not, andO.{namespaces} is the non-empty intersection ofO1.{namespaces} andO2.{namespaces}.

5 EitherO1 orO2 has{variety} =not and{namespaces} =S1, and the other has{variety} =enumeration and{namespaces} =S2, andone of the following is true

5.1 The set differenceS1 minusS2 is the empty set, andO.{variety} =any.

5.2O.{variety} =not andO.{namespaces} is the non-empty set differenceS1 minusS2.

The{disallowed names} property ofO is consistent withO beingthe wildcard union ofO1 andO2 if and only ifO.{disallowed names} includesall and only thefollowing:

1QName members ofO1.{disallowed names} that are not allowed byO2, as defined inWildcard allows Expanded Name (§3.10.4.2).

2QName members ofO2.{disallowed names} that are not allowed byO1.

3 The keyworddefined if it is contained in bothO1.{disallowed names} andO2.{disallowed names}.

Note: When one of the wildcards hasdefined in{disallowed names} and the other does not, thendefined isnot included in the union. This may allowQNames that are not allowed by either wildcard. This is to ensurethat all unions are expressible. Ifdefined is intended to beincluded, then it is necessary to have it in both wildcards.

In the case where there are more than twoNamespace Constraints to be combined, the wildcardunion is determined by identifying the wildcard union of twoof them as above, then the wildcard union of the result withthe third, and so on as required.

3.10.6.4 Attribute Wildcard Intersection

Schema Component Constraint: Attribute Wildcard Intersection

[Definition:] Given threeNamespace ConstraintsO,O1, andO2,O is thewildcard intersectionofO1 andO2 if and only ifboth its{variety} and{namespaces} properties, on theone hand, and its{disallowed names} property, on the other, areconsistent withO being the intersectionofO1 andO2, as that is defined below.

The{variety} and{namespaces} ofO are consistentwithO being the wildcardintersection ofO1 andO2 if and only ifone or more of the following is true:

1O,O1, andO2 have the same{variety} and{namespaces}.

2EitherO1 orO2 has{variety} =anyandO has{variety} and{namespaces} identicalto those of the other.

3O,O1, andO2 all have{variety} =enumeration,andO.{namespaces} is the intersection of the{namespaces} ofO1 andO2.

4O,O1, andO2 all have{variety} =not,andO.{namespaces} is the union of the{namespaces} ofO1 andO2.

5EitherO1 orO2 has{variety} =not and{namespaces} =S1 and the other has{variety} =enumeration and{namespaces} =S2,andO.{variety} =enumeration andO.{namespaces} = the set differenceS2 minusS1.

The{disallowed names} property ofO is consistentwithO being the wildcardintersection ofO1 andO2 if and only ifO.{disallowed names}includes all and only the following:

1QNamemembers ofO1.{disallowed names}whose namespace namesare allowed byO2, as defined inWildcard allows Namespace Name (§3.10.4.3).

2QNamemembers ofO2.{disallowed names}whose namespace namesare allowed byO1.

3The keyworddefined if it is a member of either{disallowed names}.

In the case where there are more than twoNamespace Constraints to be combined, the wildcardintersection is determined by identifying the wildcard intersection of twoof them as above, then the wildcard intersection of the result withthe third, and so on as required.

3.11 Identity-constraint Definitions

        3.11.1The Identity-constraint Definition Schema Component
        3.11.2XML Representation of Identity-constraint Definition Schema Components
        3.11.3Constraints on XML Representations of Identity-constraint Definitions
        3.11.4Identity-constraint Definition Validation Rules
        3.11.5Identity-constraint Definition Information Set Contributions
        3.11.6Constraints on Identity-constraint Definition Schema Components
            3.11.6.1Identity-constraint Definition Properties Correct
            3.11.6.2Selector Value OK
            3.11.6.3Fields Value OK

Identity-constraint definition components provide for uniqueness andreference 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.

3.11.1 The Identity-constraint Definition Schema Component

The identity-constraint definition schema component has the followingproperties:

Schema Component:Identity-Constraint Definition, a kind ofAnnotated Component

{annotations}

A sequence ofAnnotation components.

{name}

An xs:NCName value. Required.

{target namespace}

An xs:anyURI value. Optional.

{identity-constraint category}

One of {key,keyref,unique}. Required.

{selector}

AnXPath Expression property record. Required.

{fields}

A sequence ofXPath Expression property records.

{referenced key}

AnIdentity-Constraint Definition component. Required if{identity-constraint category} iskeyref, otherwise ({identity-constraint category} iskey orunique)must be·absent·.

If a value is present, its{identity-constraint category} must bekey orunique.

Identity-constraint definitions are identified by their{name} and{target namespace};identity-constraintdefinition identitiesmust be unique within an·XSD schema·. SeeReferences to schema components across namespaces (<import>) (§4.2.6) for the use of componentidentifiers when importing one schema into another.

Informally,{identity-constraint category} identifies theidentity-constraintdefinition as playing one ofthree roles:

(unique) theidentity-constraintdefinition asserts uniqueness, with respect to the contentidentified by{selector}, of the tuples resulting fromevaluation of the{fields} XPath expression(s).
(key) theidentity-constraintdefinition asserts uniqueness as forunique.key further asserts that all selected contentactually has such tuples.
(keyref) theidentity-constraintdefinition asserts a correspondence, with respect to the contentidentified by{selector}, of the tuples resulting fromevaluation of the{fields} XPath expression(s), with those of the{referenced key}.

These constraints are specified alongside the specification of types for theattributes and elements involved, i.e. something declared as of type integercan also serve as a key. Each constraint declaration has a name, which exists in asingle symbol space for constraints. The equality and inequalityconditionsappealed to in checking these constraints apply to thevalues ofthe fields selected, not theirlexical representation, so that for example3.0 and3would be conflicting keys if they were both decimal, but non-conflicting ifthey were both strings, or one was a string and one a decimal. When equality andidentity differ for the simple types involved, all threeforms of identity-constraint test foreither equalityor identityof values.

Overall the augmentations to XML'sID/IDREF mechanism are:

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 combinationsof 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 bedeclared to be keys, that is, not only unique, but always present and non-nillable;
The comparison betweenkeyref{fields} andkey orunique{fields} is performedon typed values, not on the lexical representations of those values.

{selector} specifies a restricted XPath([XPath 2.0]) expression relative toinstances of the element being declared. Thismust identify asequence of element nodes that arecontained within the declared elementto which the constraint applies.

{fields} specifies XPath expressions relative to eachelement selected by a{selector}. EachXPath expression in the{fields} propertymust identifya single node (element or attribute), whose content or value, whichmust beof a simple type, is used in the constraint. It is possible to specify anordered list of{fields}s, to cater to multi-field keys,keyrefs, and uniqueness constraints.

In order to reduce the burden on implementers, in particularimplementers of streaming processors, only restricted subsets of XPathexpressions are allowed in{selector} and{fields}. The details are given inConstraints on Identity-constraint Definition Schema Components (§3.11.6).

Note: Provision for multi-field keys etc. goes beyond what is supported byxsl:key.

Note: In version 1.0 of this specification[XSD 1.0 2E], identity constraints used[XPath 1.0]. They now use[XPath 2.0].

SeeAnnotations (§3.15) for information on the role of the{annotations} property.

3.11.2 XML Representation of Identity-constraint Definition Schema Components

The XML representation for an identity-constraint definition schema component is either a<key>, a<keyref> or a<unique> element information item. The correspondences between the properties of those information items after the appropriate·pre-processing· and the properties of the component they correspond to are as follows:

XML Representation Summary:unique Element Information Item et al.

<unique
 id =ID
 name =NCName
 ref =QName
 {any attributes with non-schema namespace . . .}>
 Content:(annotation?, (selector,field+)?)
</unique>

<key
 id =ID
 name =NCName
 ref =QName
 {any attributes with non-schema namespace . . .}>
 Content:(annotation?, (selector,field+)?)
</key>

<keyref
 id =ID
 name =NCName
 ref =QName
 refer =QName
 {any attributes with non-schema namespace . . .}>
 Content:(annotation?, (selector,field+)?)
</keyref>

<selector
 id =ID
 xpath =a subset of XPath expression, see below
 xpathDefaultNamespace = (anyURI | (##defaultNamespace |##targetNamespace |##local))
 {any attributes with non-schema namespace . . .}>
 Content:(annotation?)
</selector>

<field
 id =ID
 xpath =a subset of XPath expression, see below
 xpathDefaultNamespace = (anyURI | (##defaultNamespace |##targetNamespace |##local))
 {any attributes with non-schema namespace . . .}>
 Content:(annotation?)
</field>

If theref[attribute] is absent, the corresponding schema component is as follows:

XML Mapping Summary forIdentity-constraint DefinitionSchema Component

Property

Representation

The·actual value· of thename[attribute]

{identity- constraint category}

The·actual value· of thetargetNamespace[attribute] of the<schema> ancestor element information item if present, otherwise·absent·.

One ofkey,keyref orunique, depending on the item.

{selector}

AnXPath Expression property record, as described in sectionXML Representation of Assertion Schema Components (§3.13.2), with<selector> as the "host element" andxpath as the designatedexpression[attribute].

{fields}

A sequence ofXPath Expression property records, corresponding to the<field> element information item[children], in order,following the rules given inXML Representation of Assertion Schema Components (§3.13.2),with<field> as the "host element" andxpath as the designated expression[attribute].

{referenced key}

If the item is a<keyref>, theidentity-constraint definition·resolved· to by the·actual value· of therefer[attribute], otherwise·absent·.

[identity-constraint table]

The·annotation mapping· of the set of elements containing the<key>,<keyref>, or<unique> element, whichever is present, and the<selector> and<field>[children], if present, as defined inXML Representation of Annotation Schema Components (§3.15.2).

Otherwise (theref[attribute] is present), the corresponding schema component is the identity-constraint definition·resolved· to by the·actual value· of theref[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>

Astate element is defined, whichcontains acode child and somevehicle andpersonchildren. Avehicle in turn has aplateNumber attribute,which is an integer, and astate attribute. State'scodes are a key for them within the document. Vehicle'splateNumbers are a key for them within states, andstate andplateNumber is asserted to be akey forvehicle within the document as a whole. Furthermore, aperson element hasan emptycar child, withregState andregPlate attributes, which are then asserted together to refer tovehicles via thecarRef constraint. The requirementthat avehicle'sstate match its containingstate'scode is not expressed here.

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 ofstate elements can appear as child elements understateList. Akey constraint can be used to ensure that there is no duplicate statecode. We already defined akey in the above example for the exact same purpose (the key constraint is named "state"). We can reuse it directly via theref attribute on thekey element.

3.11.3 Constraints on XML Representations of Identity-constraint Definitions

Schema Representation Constraint: Identity-constraint Definition Representation OK

In addition to the conditions imposed on<key>,<keyref> and<unique> elementinformation items by the schema for schema documents,all of the followingmust be true:

1 One ofref orname is present, but not both.

2 Ifname is present, then<selector> appears in[children].

3 Ifname is present on<keyref>, thenrefer is also present.

4 Ifref is present, then onlyid and<annotation> are allowed to appear together withref.

5 Ifref is present, then the{identity-constraint category} of the identity-constraint definition·resolved· to by the·actual value· of theref[attribute] matches the name of the element information item.

3.11.4 Identity-constraint Definition Validation Rules

Validation Rule: Identity-constraint Satisfied

For an element information itemE to be locally·valid· with respect to an identity-constraintall of the followingmust be true:

1A data model instance is constructed from the input information set, as described in[XDM]. The{selector}, with the element node corresponding toE as the context node, evaluates to a sequence of element nodes, as defined inXPath Evaluation (§3.13.4.2).[Definition:] Thetarget node set is the set of nodes in that sequence, after omitting all element nodes corresponding to element information items that are·skipped·.

2Each node in the·target node set· iseither the context node or anelement node among its descendants.

3 For each nodeNin the·target node set· and each fieldF in{fields}, whenN is taken as the context nodeF evaluates (as defined inXPath Evaluation (§3.13.4.2)) to asequence of nodesS.S contains zero or more·skipped· nodes, at most one node whose·governing· typedefinition is either a simple type definition or a complex typedefinition with{variety}simple,and no other nodes.As a consequence, for each fieldF the sequenceS contains at mostone node with a·non-absent·[schema actualvalue]. Call that one node's[schema actual value]V(N,F).[Definition:] Thekey-sequence ofN is the sequence consisting of the valuesV(N,F), in the order of the{fields} property.

Note: The use of[schema actual value] in the definition of·key sequence· above means thatdefault orfixed value constraintsmay play a part in·key sequence·s.

Note: In some cases, the·key-sequence· of nodeN will be shorter than{fields} in length, for example whenever any field evaluates to the empty sequence or to a sequence consisting only of·skipped· or·nilled· nodes. In such a case, the·key-sequence· ofN does not participate in value comparison, becauseN is not a member of the·qualified node set·. See below.

4[Definition:] Thequalified node set is the subsetof the·target node set· consisting of those nodes whose·key-sequence·has the same length as the{fields}.The appropriatecase among the following is true:

4.1Ifthe{identity-constraint category} isunique,thenno two members of the·qualified node set· have·key-sequences· whose members are pairwise equal or identical, as defined byEquality andIdentity in[XML Schema: Datatypes].

4.2Ifthe{identity-constraint category} iskey,thenall of the following are true:

4.2.1The·target node set· and the·qualified node set· are equal, that is, every member of the·target node set· is also a member of the·qualified node set· andvice versa.

4.2.2No two members of the·qualified node set· have·key-sequences· whose members are pairwise equal or identical, as defined byEquality andIdentity in[XML Schema: Datatypes].

4.2.3No element member of the·key-sequence· of any member of the·qualified node set· was assessed as·valid· by reference to an element declaration whose{nillable} istrue.

4.3Ifthe{identity-constraint category} iskeyref,thenfor each member of the·qualified node set· (call this thekeyref member), there is a·node table· associated with the{referenced key} in the[identity-constraint table] ofE (seeIdentity-constraint Table (§3.11.5), which is understood as logically prior to this clause of this constraint, below) and there is an entry in that table whose·key-sequence· is equal or identical to thekeyref member's·key-sequence· member for member, as defined byEquality andIdentity in[XML Schema: Datatypes].

Note: Forunique identity constraints, the·qualified node set· isallowed to be different from the·target node set·. That is, aselected unique node may have fields that do not have corresponding[schema actual value]s.

Note: Because the validation ofkeyref (see clause4.3) depends on finding appropriate entries in an element information item's·nodetable·, and·nodetables· are assembled strictly recursively from the node tables of descendants, only element information items within the sub-tree rooted at the element information item being·validated· can be referenced successfully.

Note: Although this specification defines a·post-schema-validation infoset· contribution which would enable schema-aware processors to implement clause4.2.3 above (Element Declaration (§3.3.5.3)), processors are not required to provide it. This clause can be read as if in the absence of this infoset contribution, the value of the relevant{nillable} propertymust be available.

For purposes of checking identity-constraints, single atomic values are not distinguished from lists with single items. An atomic valueV and a listL with a single item are treated as equal, for purposes of this specification, ifV is equal to the atomic value which is the single item ofL. And similarly for identity.

3.11.5 Identity-constraint Definition Information Set Contributions

Schema Information Set Contribution: Identity-constraint Table

[Definition:] Aneligible identity-constraint of an element information item isone such that clause4.1 or clause4.2 ofIdentity-constraint Satisfied (§3.11.4) is satisfied with respect to thatitem and that constraint, or such that any of the element informationitem[children] of that item have an[identity-constraint table] property whose value has an entry forthat constraint.

[Definition:] Anodetable is a set of pairs each consisting of a·key-sequence· and an element node.

Whenever an element information item has one or more·eligible identity-constraints·, in the·post-schema-validation infoset· thatelement information item has a property as follows:

PSVI Contributions for element information items

oneIdentity-constraint Bindinginformation item for each·eligible identity-constraint·, withproperties as follows:

PSVI Contributions for Identity-constraint Binding information items

[definition]: The·eligible identity-constraint·.
[node table]: A·node table· with one entry for every·key-sequence· (call itk) andnode (call itn) such thatone of the following is true
1There is an entry in one of the·nodetables· associated with the[definition] in anIdentity-constraint Bindinginformation item in at least one of the[identity-constraint table]s of the element information item[children] of the element information item whose·key-sequence· isk and whose nodeisn;
2n appears with·key-sequence·k in the·qualified node set· for the[definition].
provided no two entries have the same·key-sequence· but distinct nodes. Potentialconflicts are resolved by not including any conflicting entries whichwould have owed their inclusion to clause1 above. Notethat if all the conflicting entries arose under clause1 above, this means no entry at all will appear for theoffending·key-sequence·.

Note: The complexity of the above arises from the fact thatkeyref identity-constraints can be defined on domains distinct from theembedded domain of the identity-constraint they reference, or on domains which are thesame but self-embedding at some depth. In either case the·nodetable· for the referenced identity-constraint needs to propagate upwards, withconflict resolution.

TheIdentity-constraint Binding information item, unlikeothers in this specification, is essentially an internal bookkeepingmechanism. It is introduced to support the definition ofIdentity-constraint Satisfied (§3.11.4)above.

3.11.6 Constraints on Identity-constraint Definition Schema Components

3.11.6.1 Identity-constraint Definition Properties Correct

All identity-constraint definitions (seeIdentity-constraint Definitions (§3.11))must satisfy the following constraint.

Schema Component Constraint: Identity-constraint Definition Properties Correct

All of the followingmust be true:

1The values of the properties of an identity-constraint definition are as described in the property tableau inThe Identity-constraint Definition Schema Component (§3.11.1), modulo the impact ofMissing Sub-components (§5.3).

2If the{identity-constraint category} iskeyref, the cardinality of the{fields} is equal to that of the{fields} of the{referenced key}.

3.11.6.2 Selector Value OK

Schema Component Constraint: Selector Value OK

All of the followingmust be true:

1The{selector} satisfies the constraintXPath Valid (§3.13.6.2).

2One or more of the following is true:

2.1 Its{expression} conforms to the following extended BNF:

[1]	`Selector`	::=	`Path ( '\|'Path )*`
[2]	`Path`	::=	`('.' '//')?Step ( '/'Step )*`
[3]	`Step`	::=	`'.' \|NameTest`
[4]	`NameTest`	::=	`QName \| '' \|NCName ':'`

2.2Its{expression} is an XPath expression involving thechild axis whose abbreviated form is as given above.

For readability, whitespacemay be used in selector XPath expressions even though not explicitly allowed by the grammar:whitespacemay be freely added within patterns before or after anytoken.

[5]	`token`	::=	`'.' \| '/' \| '//' \| '\|' \| '@' \|NameTest`
[6]	`whitespace`	::=	`S`

When tokenizing, the longest possible token is always returned.

[Definition:] The subset of XPath defined inSelector Value OK (§3.11.6.2) is called theselector subset of XPath.

3.11.6.3 Fields Value OK

Schema Component Constraint: Fields Value OK

All of the followingmust be true:

1Each member of the{fields} satisfies the constraintXPath Valid (§3.13.6.2).

2 For each member of the{fields}one or more of the following is true:

2.1 Its{expression} conforms to the extended BNF givenabove forSelector, with the following modification:

[7] Path ::= ('.' '//')? (Step '/' )* (Step | '@'NameTest )

This production differs from the one above in allowing the finalstep to match an attribute node.

2.2Its{expression} is an XPath expression involving thechild and/orattribute axes whose abbreviated form isas given above.

For readability, whitespacemay be used in field XPath expressions even though notexplicitly allowed by the grammar:whitespacemay be freely added within patterns before or after anytoken.

When tokenizing, the longest possible token is always returned.

[Definition:] The subset of XPath defined inFields Value OK (§3.11.6.3) is called thefield subset of XPath.

3.12 Type Alternatives

        3.12.1The Type Alternative Schema Component
        3.12.2XML Representation of Type Alternative Schema Components
        3.12.3Constraints on XML Representations of Type Alternatives
        3.12.4Type Alternative Validation Rules
        3.12.5Type Alternative Information Set Contributions
        3.12.6Constraints on Type Alternative Schema Components

Type Alternative components provide associations between boolean conditions (as XPath expressions) andType Definitions. They are used in conditional type assignment.

3.12.1 The Type Alternative Schema Component

The type alternative schema component has the following properties:

Schema Component:Type Alternative, a kind ofAnnotated Component

{annotations}

A sequence ofAnnotation components.

{test}

AnXPath Expression property record. Optional.

{type definition}

AType Definition component. Required.

Type alternatives can be used by anElement Declaration to specify a condition ({test}) under which a particular type ({type definition}) is used as the·governing type definition· for element information items governed by thatElement Declaration. EachElement Declarationmay have multipleType Alternatives in its{type table}.

3.12.2 XML Representation of Type Alternative Schema Components

The XML representation for a type alternative schema component is an<alternative> element information item. The correspondences between the properties of that information item after the appropriate·pre-processing· and the properties of the component it corresponds to are as follows:

XML Representation Summary:alternative Element Information Item

<alternative
 id =ID
 test =an XPath expression
 type =QName
 xpathDefaultNamespace = (anyURI | (##defaultNamespace |##targetNamespace |##local))
 {any attributes with non-schema namespace . . .}>
 Content:(annotation?, (simpleType |complexType)?)
</alternative>

Each<alternative> element maps to aType Alternative component as follows.

XML Mapping Summary forType AlternativeSchema Component

Property

Representation

{test}

If thetest[attribute] is not present, then·absent·; otherwise anXPath Expression property record, as described in sectionXML Representation of Assertion Schema Components (§3.13.2), with<alternative> as the "host element" andtest as the designated expression[attribute].

The type definition·resolved· to by the·actual value· of thetype[attribute], if one is present, otherwise the type definition correspondingto thecomplexType orsimpleType among the[children] of the<alternative> element.

The·annotation mapping· of the<alternative> element, as defined inXML Representation of Annotation Schema Components (§3.15.2).

3.12.3 Constraints on XML Representations of Type Alternatives

Schema Representation Constraint: TypeAlternative Representation OK

In addition to the conditions imposed on<alternative> element information items by the schema for schema documents,each<alternative> elementmust have one (and only one)of the following: atype attribute, or acomplexType child element, or asimpleType child element.

3.12.4 Type Alternative Validation Rules

[Definition:] AType AlternativeAsuccessfully selects aType DefinitionT for an element information itemE if and only ifA.{test} evaluates totrue andA.{type definition} =T. The{test} is evaluated in the following way:

1 An instance of the[XDM] data model is constructed as follows:

1.1 An information set is constructed by copying the base information set properties (and not any of the properties specific to·post-schema-validation infoset·) of the following information items:

1.1.1E itself.

1.1.2E's[attributes] (but not its[children]).

1.1.3E's[inherited attributes] which do not have the sameexpanded names as any ofE's[attributes]. They are copied as if they were amongE's[attributes] and hadE as their[owner element]. When an attribute with a non-empty[namespace name] is copied,·namespace fixup· may need to be performed on the resulting information set to ensure that a prefixP is bound to the[namespace name] and the[prefix] of the copied attribute is set toP.

[Definition:] Bybase information set properties are meant the properties listed inRequired Information Set Items and Properties (normative) (§D).

1.2 In the copy ofE, the[parent] property is modified to have no value. The[children] property is modified to have the empty list as its value.

1.3 An[XDM] data model instance is constructed from that information set, following the rules given in[XDM].

2 The XPath expression which is the value of the{test}, is evaluated as described inXPath Evaluation (§3.13.4.2). If adynamic error or atype error is raised during evaluation, then the{test} is treated as if it had evaluated (without error) tofalse.

Note:Dynamic errors andtype errors in the evaluation of{test} expressions cause neither the schema nor the document instance to be invalid. But conforming processorsmay issue a warning if they occur. However, if type errors are detected statically by the XPath processor, the effect is the same as for other static errors in the XPath expression.

Note: As a consequence of the rules just given, the root node of the[XDM] instance is necessarily constructed fromE; the ancestors, siblings, children, and descendants ofE are not represented in the data model instance, and they are thus not accessible to the tests expressed in the{test}s in the{type table}. The elementE and its[attributes] will be represented in the data model instance by nodes labeled as untyped. If the{test} expressions being evaluated include comparisons which require type information, then explicit casts will sometimes be necessary.

3.12.5 Type Alternative Information Set Contributions

None.

3.12.6 Constraints on Type Alternative Schema Components

All type alternatives (seeType Alternatives (§3.12))must satisfy the following constraints.

Schema Component Constraint: Type Alternative Properties Correct

All of the followingmust be true:

1 The values of the properties of a type alternatives are as described in the property tableau inThe Type Alternative Schema Component (§3.12.1), modulo the impact ofMissing Sub-components (§5.3).

2 If the{test} is not·absent·, then it satisfies the constraintXPath Valid (§3.13.6.2). Thefunction signatures in thestatic contextmust include signatures forall of the following:

2.1Thefn:not function defined in the[Functions and Operators] specification.

2.2Constructor functions for the built-in datatypes.

The further contents offunction signatures are·implementation-defined·.

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

Note: Any XPath expression containing no static errors as defined in[XPath 2.0] may appear in a conforming schema. Conforming processorsmay 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 ifall of the following are true:

1 The{expression} property of theXPath Expression is an XPath expression containing no static errors, as defined in[XPath 2.0].

2One or more of the following is true:

2.1 It conforms to the following extended BNF:

[8]	`Test`	::=	`OrExpr`
[9]	`OrExpr`	::=	`AndExpr ( 'or'AndExpr )*`
[10]	`AndExpr`	::=	`BooleanExpr ( 'and'BooleanExpr )*`
[11]	`BooleanExpr`	::=	`'('OrExpr ')' \|`
			`BooleanFunction \|`
			`ValueExpr (ComparatorValueExpr )?`
[12]	`BooleanFunction`	::=	`QName '('OrExpr ')'`
[13]	`Comparator`	::=	`'=' \| '!=' \| '<' \| '<=' \| '>' \| '>='`
[14]	`ValueExpr`	::=	`CastExpr \|ConstructorFunction`
[15]	`CastExpr`	::=	`SimpleValue ( 'cast' 'as' QName '?'? )?`
[16]	`SimpleValue`	::=	`AttrName \|Literal`
[17]	`AttrName`	::=	`'@'NameTest`
[18]	`ConstructorFunction`	::=	`QName '('SimpleValue ')'`

2.2 It is an XPath expression involving theattribute axis 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 Any strings matching theBooleanFunction production are function calls tofn:not defined in the[Functions and Operators] specification. Any strings matching theConstructorFunction production are function calls to constructor functions for the built-in datatypes.

Note: The minimal content of thefunction signatures in thestatic context is given in clause2 ofType Alternative Properties Correct (§3.12.6):fn:not and constructors for the built-in datatypes.

Note: The above extended BNF is ambiguous. For example, the string "a:b('123')" has 2 paths in the grammar, by matching eitherBooleanFunction orConstructorFunction. The rules given here require different function names for the productions. As a result, the ambiguity can be resolved based on the function name.

4 Any explicit casts (i.e. any strings which match the optional "cast as"QName in theCastExpr production) are casts to built-in datatypes.

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

Note: The rule given above for the construction of the data modelinstance has as a consequence that even when implementationssupport full[XPath 2.0] expressions, it is notpossible to refer successfully to the children, siblings,ancestors, etc. of the element whose type is being selected.

3.13 Assertions

        3.13.1The Assertion Schema Component
        3.13.2XML Representation of Assertion Schema Components
        3.13.3Constraints on XML Representations of Assertions
        3.13.4Assertion Validation Rules
            3.13.4.1Assertion Satisfied
            3.13.4.2XPath Evaluation
        3.13.5Assertion Information Set Contributions
        3.13.6Constraints on Assertion Schema Components
            3.13.6.1Assertion Properties Correct
            3.13.6.2XPath 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> element requires that the value of themin attribute be less than or equal to that of themax attribute, and fails if that is not the case.

3.13.1 The Assertion Schema Component

The assertion schema component has the following properties:

Schema Component:Assertion, a kind ofAnnotated Component

{annotations}

A sequence ofAnnotation components.

{test}

AnXPath Expression property record. Required.

Property Record:XPath Expression

{namespace bindings}

A set ofNamespace Binding property records.

{default namespace}

An xs:anyURI value. Optional.

{base URI}

An xs:anyURI value. Optional.

{expression}

An[XPath 2.0] expression. Required.

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]) is constructed, in which the element information item being·assessed· is the (parentless) root node, and elements and attributes are assigned types and values according to XPath 2.0 data model construction rules, with some exceptions. SeeAssertion Satisfied (§3.13.4.1) for details about how the data model is constructed. When evaluated against this data model instance,{test} evaluates to eithertrue orfalse (if any other value is returned, it's converted to eithertrue orfalse as if by a call to the XPathfn:boolean function).

SeeAnnotations (§3.15) for information on the role of the{annotations} property.

3.13.2 XML Representation of Assertion Schema Components

The XML representation for an assertion schema component is an<assert> element information item. The correspondences between the properties of that information item after the appropriate·pre-processing· and the properties of the component it corresponds to are as follows:

XML Representation Summary:assert Element Information Item

<assert
 id =ID
 test =an XPath expression
 xpathDefaultNamespace = (anyURI | (##defaultNamespace |##targetNamespace |##local))
 {any attributes with non-schema namespace . . .}>
 Content:(annotation?)
</assert>

The<assert> element maps to anAssertion component as follows.

XML Mapping Summary forAssertionSchema Component

Property

Representation

{test}

AnXPath Expression property record, as described below,with<assert> as the "host element"andtest as the designated expression[attribute].

The·annotation mapping· of the<assert> element, as defined inXML Representation of Annotation Schema Components (§3.15.2).

Assertions, like identity constraints and conditional type assignment, use[XPath 2.0] expressions. The expression itself is recorded, together with relevant parts of the context, in anXPath Expression property record. The mapping is as described below; in each case, the XPath expression itself is given in adesignated attribute of the appropriate "host element".

XML Mapping Summary forXPath ExpressionProperty Record

Property

Representation

{namespace bindings}

A set ofNamespace Binding property records. Each member corresponds to an entry in the[in-scope namespaces] of the host element, with{prefix} being the[prefix] and{namespace} the[namespace name].

{default namespace}

LetD be the·actual value· of thexpathDefaultNamespace[attribute], if present on the host element, otherwise that of thexpathDefaultNamespace[attribute] of the<schema> ancestor. Then the value is the appropriatecase among the following:

1IfD is##defaultNamespace,thenthe appropriatecase among the following:

1.1Ifthere is an entry in the[in-scope namespaces] of the host element whose[prefix] is·absent·,thenthe corresponding[namespace name];

1.2otherwise·absent·;

2IfD is##targetNamespace,thenthe appropriatecase among the following:

2.1IfthetargetNamespace[attribute] is present on the<schema> ancestor,thenits·actual value·;

2.2otherwise·absent·;

3IfD is##local,then·absent·;

4otherwise(D is an xs:anyURI value)D.

{base URI}

The[base URI] of the host element.

{expression}

An XPath expression corresponding to the·actual value· of the designated[attribute] of the host element.

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 themin attribute must be less than or equal to that of themax attribute.Note that the attributes are validated before the assertion on the parent element is checked, so the typed values of the attributesare available for comparison; it is not necessary to cast the valuestoint or some other numeric type before comparing them.

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 thelength attribute must be the same as the number of occurrences ofentry sub-elements.

3.13.3 Constraints on XML Representations of Assertions

None as such.

3.13.4 Assertion Validation Rules

3.13.4.1 Assertion Satisfied

Validation Rule: Assertion Satisfied

An element information itemE is locally·valid· with respect to anassertion if and only if the{test} evaluates totrue (see below) without raising anydynamic error ortype error.

Evaluation of{test} is performed as definedin[XPath 2.0], with the following conditions:

1 A data model instance (see[XDM]) is constructed in the following way:

1.1E is validated with respect to its·governing element declaration·, as defined inElement Locally Valid (Element) (§3.3.4.3), if the·governing element declaration· exists, otherwise against its·governing type definition·, as defined inElement Locally Valid (Complex Type) (§3.4.4.2), except that forE itself (though not for its element information item descendants), clause6 ofElement Locally Valid (Complex Type) (§3.4.4.2) is skipped. (Informally, the element is validated normally, except that assertions are not checked.)

Note: It is a consequence of this rule that the[attributes] and[children] ofE will be validated in the usual way.

1.2A "partial"·post-schema-validation infoset· describing the results of this partial validation ofE is constructed. The·post-schema-validation infoset· properties ofE's[children] and[attributes] are defined in the usual way. OnE itself, all·post-schema-validation infoset· properties are supplied as described elsewhere in this specification if their values are known. The element's[validity] property is given the valueinvalid if and only if the element is known to be invalid; otherwise it is given the valuenotKnown. The element's[validation attempted] property is given the valuepartial.

Note: Since the assertions of its·governing type definition· have not been checked,E has been only partially validated, and can be known to be invalid, but not known to be valid. The values of the[validity] and[validation attempted] properties are set accordingly.

By default, comments and processing instructions are excluded from the partial·post-schema-validation infoset·, but·at useroption· processorsmay retain comments and processing instructions instead of excluding them.

Note: If comments and processing instructions are retained, the consequence will be that assertions are able to test for their presence or absence and to examine their contents.

1.3From the "partial"·post-schema-validation infoset·, a data model instance is constructed as described in[XDM]. The root node of the[XDM] instance is constructed fromE; the data model instance contains only that node and nodes constructed from the[attributes],[children], and descendants ofE.

Note: It is a consequence of this construction that attempts to refer, in an assertion, to the siblings or ancestors ofE, or to any part of the input document outside ofE itself, will be unsuccessful. Such attempted references are not in themselves errors, but the data model instance used to evaluate them does not include any representation of any parts of the document outside ofE, so they cannot be referred to.

2 The XPath expression{test} is evaluated, following the rules given inXPath Evaluation (§3.13.4.2), with the following conditions and modifications:

2.1The root node of the[XDM] instance described in clause1 serves as thecontext node for evaluation of the XPath expression.

2.2Thestatic context is augmented with the variable "$value", as described inAssertion Properties Correct (§3.13.6.1).

2.3 The variable "$value" appears as a member of thevariable values in thedynamic context. Theexpanded QName of that member has no namespace URI and has "value" as the local name. Thevalue of the member is determined by the appropriatecase among the following:

2.3.1Ifall of the following are true:

2.3.1.1E's[validity] in the "partial"·post-schema-validation infoset· is notinvalid;

2.3.1.2E's[nil] in the "partial"·post-schema-validation infoset·does not exist or has valuefalse;

2.3.1.3the{content type} ofE's·governing type definition·has{variety}simple,

then thevalue is theXDM representation ofE.[schema actual value]under the{content type} .{simple type definition} ofE's·governing type definition·.

Note: This clause provides type information to simple contents of elements, to make type-aware comparisons and operations possible without explicit casting in the XPath expressions.

Note: For complex types with simple content, the element node may be referred to as ".", while its content may be referred to as "$value". Since the element node, as a consequence of clause1.2, will normally have the type annotationanyType, itsatomized value will be a single atomic value of typeuntypedAtomic. By contrast,$value will be a sequence of one or more atomic values, whose types are the most specific (narrowest) built-in types available.

2.3.2otherwise(in the "partial"·post-schema-validation infoset·,E.[validity] =invalid orE.[nil] =true orE's·governing type definition· does not have{content type} .{variety} =simple) thevalue is the empty sequence.

3 The evaluation result is converted to eithertrue orfalse as if by a call to the XPathfn:boolean function.

Note: Although the rules just given describe how an·post-schema-validation infoset· and a[XDM] instance are constructed, processors are not required to construct actual data structures representing them. However, the result of XPath evaluationmust be the same as if such·post-schema-validation infoset· and[XDM] instance data structures were constructed.

3.13.4.2 XPath Evaluation

Validation Rule: XPath Evaluation

AnXPath Expression property recordX, with a context nodeE, is evaluated as defined in[XPath 2.0], with astatic context as described inXPath Valid (§3.13.6.2)(unless otherwise specifiedelsewhere) and with the followingdynamic context(again, unless otherwise specifiedelsewhere):

1Thecontext item isE.

2Thecontext position is 1.

3Thecontext size is 1.

4Thevariable values is the empty set.

5Thefunction implementations include an implementation of every function in thefunction signatures of thestatic context. SeeXPath Valid (§3.13.6.2).

6Thecurrent dateTime is·implementation-defined·, but is constant during an·assessment· episode.

7Theimplicit timezone is·implementation-defined·, but is constant during an·assessment· episode.

8Theavailable documents is the empty set.

9Theavailable collections is the empty set.

10Thedefault collection is the empty sequence.

It is·implementation-defined· (both in this specification and in[XPath 2.0]) when type errors are detected and whether, when detected, they are treated as static or dynamic errors.

Note: It is a consequence of this rule that a conforming processor which treats a type error in an XPath expression as a dynamic error will treat the expression as having evaluated to false, while a conforming processor which treats type errors as static errors will report an error in the schema.

3.13.5 Assertion Information Set Contributions

None as such.

3.13.6 Constraints on Assertion Schema Components

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

3.13.6.1 Assertion Properties Correct

Schema Component Constraint: Assertion Properties Correct

All of the followingmust be true:

1 The values of the properties of an assertion are as described in the property tableau inThe Assertion Schema Component (§3.13.1), modulo the impact ofMissing Sub-components (§5.3).

2 The{test} satisfies the constraintXPath Valid (§3.13.6.2), with the following modifications to thestatic context:

2.1 Thein-scope variables is a set with a single member. Theexpanded QName of that member has no namespace URI and hasvalue as the local name. The (static)type of the member isanyAtomicType*.

2.2 Thefunction signatures includes signatures forall of the following:

2.2.1 Functions in thehttp://www.w3.org/2005/xpath-functions namespace as defined in the[Functions and Operators] specification.

2.2.2 Constructor functions for the built-in datatypes.

Note: The XDM type labelanyAtomicType* simply says that for static typing purposes the variable$value will have a value consisting of a sequence of zero or more atomic values.

3.13.6.2 XPath Valid

Schema Component Constraint: XPath Valid

For anXPath Expression property recordXto be valid,all of the followingmust be true:

1 The{expression} ofX is a valid XPath expression, as defined in[XPath 2.0].

2X does not produce anystatic error, under the following conditions (except as specified elsewhere):

2.1 TheStatic Typing Feature is disabled.

2.2 Thestatic context is given as follows:

2.2.1XPath 1.0 compatibility mode isfalse.

2.2.2Thestatically known namespaces is the{namespace bindings} ofX.

2.2.3Thedefault element/type namespace is the{default namespace}ofX.

2.2.4Thedefault function namespace ishttp://www.w3.org/2005/xpath-functions.

2.2.5Thein-scope schema definitionsare those components that are present in every schema by definition,as defined inBuilt-in Attribute Declarations (§3.2.7),Built-in Complex Type Definition (§3.4.7) andBuilt-in Simple Type Definitions (§3.16.7).

2.2.6Thein-scope variablesis the empty set.

2.2.7Thecontext item static type is not applicable, because theStatic Typing Feature is disabled.

2.2.8Thefunction signatures are·implementation-defined·.

Note: IfX belongs to anAssertion or aType Alternative,Assertion Properties Correct (§3.13.6.1) andType Alternative Properties Correct (§3.12.6) impose additional constraints on the set of required functions.

2.2.9Thestatically known collations are·implementation-defined·, but always include theUnicode codepoint collation(http://www.w3.org/2005/xpath-functions/collation/codepoint)defined by[Functions and Operators].

2.2.10Thedefault collationis the Unicode codepoint collation.

2.2.11Thebase URI is the{base URI} ofX.

2.2.12Thestatically known documents is the empty set.

2.2.13Thestatically known collections is·implementation-defined·.

2.2.14Thestatically known default collection type is·implementation-defined·.

It is·implementation-defined· (both in this specification and in[XPath 2.0]) when type errors are detected and whether, when detected, they are treated as static or dynamic errors.

3.14 Notation Declarations

        3.14.1The Notation Declaration Schema Component
        3.14.2XML Representation of Notation Declaration Schema Components
        3.14.3Constraints on XML Representations of Notation Declarations
        3.14.4Notation Declaration Validation Rules
        3.14.5Notation Declaration Information Set Contributions
        3.14.6Constraints 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.

3.14.1 The Notation Declaration Schema Component

The notation declaration schema component has the followingproperties:

Schema Component:Notation Declaration, a kind ofAnnotated Component

{annotations}

A sequence ofAnnotation components.

{name}

An xs:NCName value. Required.

{target namespace}

An xs:anyURI value. Optional.

{system identifier}

An xs:anyURI value. Required if{public identifier} is·absent·, otherwise ({public identifier} is present) optional.

{public identifier}

A publicID value. Required if{system identifier} is·absent·, otherwise ({system identifier} is present) optional.

As defined in[XML 1.0] or[XML 1.1].

Notation declarations do not participate in·validation· as such. They are referenced in thecourse of·validating· strings asmembers of theNOTATION simple type. An element or attribute information item withits·governing· type definition or its·validating type·derived from theNOTATIONsimple type is·valid· only if itsvalue was among the enumerations of such simple type.As a consequence such a value is required to be the{name}of a notation declaration.

SeeAnnotations (§3.15) for information on the role of the{annotations} property.

3.14.2 XML Representation of Notation Declaration Schema Components

The XML representation for a notation declaration schema component isa<notation>element information item. The correspondences between theproperties of that information itemafter the appropriate·pre-processing·and theproperties of the component it corresponds to are as follows:

XML Representation Summary:notation Element Information Item

<notation
 id =ID
 name =NCName
 public =token
 system =anyURI
 {any attributes with non-schema namespace . . .}>
 Content:(annotation?)
</notation>

The<notation> element maps to aNotation Declaration component as follows.

XML Mapping Summary forNotation DeclarationSchema Component

Property

Representation

The·actual value· of thename[attribute]

The·actual value· of thetargetNamespace[attribute] of the<schema> ancestorelement information item if present, otherwise·absent·.

{system identifier}

The·actual value· of thesystem[attribute], if present, otherwise·absent·.

{public identifier}

The·actual value· of thepublic[attribute], if present, otherwise·absent·.

{application information}

The·annotation mapping· of the<notation> element, as defined inXML 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>

3.14.3 Constraints on XML Representations of Notation Declarations

None as such.

3.14.4 Notation Declaration Validation Rules

None as such.

3.14.5 Notation Declaration Information Set Contributions

Schema Information Set Contribution: Validated with Notation

Whenever an attribute information item is·valid· with respect to aNOTATION, in the·post-schema-validation infoset· itsparent element information item has the followingproperties:

PSVI Contributions for element information items

[notation]: An·item isomorphic· to the notation declaration·resolved· to by theattribute item's·actual value·
[notation system]: The value of the{system identifier} of that notationdeclaration.
[notation public]: The value of the{public identifier} of that notationdeclaration.

Note: For compatibility, only one such attributeshould appearon any given element. If more than one such attributedoes appear, which one supplies the infoset property orproperties above is not defined.

Note: Element as well as attribute information items may be·valid· with respect to aNOTATION, but only attributeinformation items cause a notation declaration to appear in the·post-schema-validation infoset· as a property of their parent.

3.14.6 Constraints on Notation Declaration Schema Components

All notation declarations (seeNotation Declarations (§3.14))must satisfy the following constraint.

Schema Component Constraint: Notation Declaration Correct

The values of the properties of a notation declarationmust be as described in the property tableau inThe Notation Declaration Schema Component (§3.14.1), modulo the impact ofMissing Sub-components (§5.3).

3.15 Annotations

        3.15.1The Annotation Schema Component
        3.15.2XML Representation of Annotation Schema Components
        3.15.3Constraints on XML Representations of Annotations
        3.15.4Annotation Validation Rules
        3.15.5Annotation Information Set Contributions
        3.15.6Constraints 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.

3.15.1 The Annotation Schema Component

The annotation schema component has the following properties:

Schema Component:Annotation, a kind ofComponent

{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} is intended for human consumption,{application information} for automatic processing. In both cases, provision is made for an optional URI reference to supplement the local information, as the value of thesource attribute of the respective element information items.·validation· doesnot involve dereferencing these URIs, when present. In the case of{user information}, indicationshould be given as to the identity of the (human) language used in the contents, using thexml:lang attribute.

{attributes} ensures that when schema authors take advantage of the provision for adding attributes from namespaces other than the XSD namespace to schema documents, they are available within the components corresponding to the element items where such attributes appear.

Annotations do not participate in·validation· as such. Providedan annotation itself satisfies all relevant·Schema Component Constraints· itcannot affect the·validation· of element informationitems.

The mapping defined in this specification from XML representations tocomponents does not apply to XML elements contained within an<annotation> element; such elements do not correspond tocomponents, when the mapping defined here is used.

It is·implementation-defined· what effect, if any, the invalidity of a descendant of<annotation> has on the construction of schema components from the enclosing schema document.

The name[Definition:] Annotated Component covers all the different kinds of component which mayhave annotations.

3.15.2 XML Representation of Annotation Schema Components

Annotation of schemas and schema components, with material for human orcomputer consumption, is provided for by allowing application information andhuman information at the beginning of most major schema elements, and anywhereat the top level of schemas. The XML representation for an annotation schema component isan<annotation>element information item. The correspondences between theproperties of that information item after the appropriate·pre-processing·and theproperties of the component it corresponds to are as follows:

XML Representation Summary:annotation Element Information Item et al.

<annotation
 id =ID
 {any attributes with non-schema namespace . . .}>
 Content:(appinfo |documentation)*
</annotation>

<appinfo
 source =anyURI
 {any attributes with non-schema namespace . . .}>
 Content:({any})*
</appinfo>

<documentation
 source =anyURI
 xml:lang =language
 {any attributes with non-schema namespace . . .}>
 Content:({any})*
</documentation>

The<annotation> element and its descendants map to anAnnotation component as follows.

XML Mapping Summary forAnnotationSchema Component

Property

Representation

A sequence ofthe<appinfo> element information items fromamong the[children], in order, if any, otherwise the emptysequence.

{user information}

A sequence of the<documentation> element information items fromamong the[children], in order, if any, otherwise the emptysequence.

{attributes}

A set of attribute information items,namely those allowed by the attribute wildcard in the typedefinition for the<annotation> item itself orfor theenclosing items which correspond to the component within whichthe annotation component is located.

The annotation component corresponding to the<annotation> element in the example above will have one element item in each of its{user information} and{application information} and one attribute item in its{attributes}.

Virtually every kind of schema component defined in this specificationhas an{annotations} property. Whenthe component is described in a schema document, the mapping fromthe XML representation of the component to theAnnotationcomponents in the appropriate{annotations} property follows the rules described in the next paragraph.

[Definition:] Theannotationmapping of a set of element information itemsESis a sequence of annotationsAS, with the following properties:

1For every<annotation> element information item among the[children] of any element information item inES, thereis a correspondingAnnotation component inAS.

Note: As noted above,the{attributes} property ofeachAnnotation component includes allthe attribute information items on the<annotation> element itself, on theXML element which represents (and maps to) thecomponent being annotated, and on any interveningXML elements, if those attribute information itemshave[namespace name]s different from the XSD namespace.

2If any element information itemE inES has any attribute information itemsA such thatall of the following are true:

2.1A is inE.[attributes].

2.2A.[namespace name]is present and not the XSD namespace.

2.3A is not included in the[attributes] property of any annotation component described in clause1.

then for each suchE, anAnnotation componentC will appear inAS, withC.{application information}andC.{user information}each being the empty sequence andC.{attributes}containing all and only those attribute informationitemsA amongE.[attributes].

3AS contains no otherAnnotation components.

[Definition:] Theannotationmapping of a single element information item is the·annotation mapping· of the singleton set containing thatelement.

Note: The order ofAnnotation components within the sequence is·implementation-dependent·.

Note: When the input set has more than onemember, theAnnotation components in the resulting sequencedo not record which element in the set theycorrespond to. The attribute information items in the{attributes} of anyAnnotationsimilarly do not indicate which element information item in theschema document was their parent.

3.15.3 Constraints on XML Representations of Annotations

None as such.

3.15.4 Annotation Validation Rules

None as such.

3.15.5 Annotation Information Set Contributions

None as such: the addition of annotations to the·post-schema-validation infoset· is covered by the·post-schema-validation infoset· contributions of the enclosing components.

3.15.6 Constraints on Annotation Schema Components

All annotations (seeAnnotations (§3.15))must satisfy the following constraint.

Schema Component Constraint: Annotation Correct

The values of the properties of an annotationmust be as described inthe property tableau inThe Annotation Schema Component (§3.15.1), modulo the impact ofMissing Sub-components (§5.3).

3.16 Simple Type Definitions

Note: This section consists of a combination of copies ofnormative material from[XML Schema: Datatypes], for local cross-referencepurposes, and materialunique to this specification, relating to the interface between schemacomponents defined in this specification and the simple type definition component.

Simple type definitions provide for constraining character information item[children] of element and attributeinformation items.

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.

3.16.1 The Simple Type Definition Schema Component

The simple type definition schema component has the following properties:

Schema Component:Simple Type Definition, a kind ofType Definition

{annotations}

A sequence ofAnnotation components.

{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} is·absent·, otherwisemust be·absent·.

Either anAttribute Declaration, anElement Declaration, aComplex Type Definition, or aSimple Type Definition.

{base type definition}

AType Definition component. Required.

With one exception, the{base type definition} of anySimple Type Definition is aSimple Type Definition. The exception is·xs:anySimpleType·, which has·xs:anyType·, aComplex Type Definition, as its{base type definition}.

{facets}

A set ofConstraining Facet components.

{fundamental facets}

A set ofFundamental Facet components.

{variety}

One of {atomic,list,union}. Required for allSimple Type Definitions except·xs:anySimpleType·, in which it is·absent·.

{primitive type definition}

ASimple Type Definition component. With one exception, required if{variety} isatomic, otherwisemust be·absent·. The exception is·xs:anyAtomicType·, whose{primitive type definition} is·absent·.

If non-·absent·,must be aprimitive definition.

{item type definition}

ASimple Type Definition component. Required if{variety} islist, otherwisemust be·absent·.

The value of this propertymust be a primitive or ordinary simple type definitionwith{variety} =atomic,or an ordinary simple type definition with{variety} =unionwhose basic members are all atomic; the valuemust not itself be a list type (have{variety} =list)or have any basic members which are list types.

{member type definitions}

A sequence of primitive or ordinarySimple Type Definition components.

Must be present (butmay be empty) if{variety} isunion, otherwisemust be·absent·.

The sequence may contain any primitive or ordinary simple type definition, butmust not contain any special type definitions.

Simple types are identified by their{name} and{target namespace}. Exceptfor anonymous simple types (those with no{name}), sincetype definitions (i.e. both simple and complex type definitions taken together)must be uniquely identified within an·XSD schema·, no simple type definition can have the same name as anothersimple or complex type definition. Simple type{name}s and{target namespace}sare provided for reference frominstances (seexsi:type (§2.7.1)), and for use in the XMLrepresentation of schema components(specifically in<element> and<attribute>). SeeReferences to schema components across namespaces (<import>) (§4.2.6) for the use of componentidentifiers when importing one schema into another.

Note: The{name} of a simple type is notipsofacto the[(local) name] of the element or attribute information items·validated· by that definition. The connection between a name and a type definition is described inElement Declarations (§3.3) andAttribute Declarations (§3.2).

A simple type definition with an empty specification for{final} can be used as the{base type definition} for other types·derived· by either ofextension or restriction, or as the{item type definition} inthe definition of a list, or in the{member type definitions} ofa union; the explicit valuesextension,restriction,list andunion prevent further·derivations· by extension (to yield a complex type) and restriction (to yield asimple type) and use in·constructing· lists and unions respectively.

{variety} determines whether the simple type corresponds toanatomic,list orunion type as defined by[XML Schema: Datatypes].

As described inType Definition Hierarchy (§2.2.1.1), every simple type definition isa·restriction· of some other simpletype (the{base type definition}), which is·xs:anySimpleType· if and only if the typedefinition in question is·xs:anyAtomicType· or a list orunion type definition which is not itself·derived· by restriction from alist or union respectively.A type definitionhas·xs:anyAtomicType· as its{base type definition} if and only if it is one of the primitive datatypes. Eachatomic type is ultimately a restriction of exactly one such primitive datatype, which is its{primitive type definition}.

The{facets} property contains a set of constraining facets which are used to specify constraints on the datatype described by the simple type definition. Foratomic definitions, these are restricted to those appropriate for the corresponding{primitive type definition}. Therefore, the value space and lexical space (i.e. what is·validated· by any atomic simple type) is determined by the pair ({primitive type definition},{facets}).

Constraining facets are defined in[XML Schema: Datatypes]. All conforming implementations of this specificationmust support all of the facets defined in[XML Schema: Datatypes]. It is·implementation-defined· whether additional facets are supported; if they are, the implementationmust satisfy the rules for·implementation-defined· facets described in[XML Schema: Datatypes].

As specified in[XML Schema: Datatypes],list simple type definitions·validate· space separated tokens, each ofwhich conforms to a specified simple type definition, the{item type definition}. The item type specifiedmust not itself be alist type, andmust be one of the types identified in[XML Schema: Datatypes] as asuitable item type for a list simple type. In this case the{facets}apply to the list itself, and are restricted to those appropriate for lists.

Aunion simple type definition·validates· strings which satisfy atleast one of its{member type definitions}. As in the case oflist, the{facets}apply to the union itself, and are restricted to those appropriate for unions.

·xs:anySimpleType· or·xs:anyAtomicType·mustnot be named as the{base type definition} of any user-defined atomic simple type definitions: as they allow no constraining facets, this would be incoherent.

SeeAnnotations (§3.15) for information on the role of the{annotations} property.

3.16.2 XML Representation of Simple Type Definition Schema Components

As always, the mapping rules given in this section apply after, not before, the appropriate·pre-processing·.

Note: This section reproduces a version of material from[XML Schema: Datatypes], for local cross-reference purposes.

XML Representation Summary:simpleType Element Information Item et al.

<simpleType
 final = (#all | List of (list |union |restriction |extension))
 id =ID
 name =NCName
 {any attributes with non-schema namespace . . .}>
 Content:(annotation?, (restriction |list |union))
</simpleType>

<restriction
 base =QName
 id =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})*))
</restriction>

<list
 id =ID
 itemType =QName
 {any attributes with non-schema namespace . . .}>
 Content:(annotation?,simpleType?)
</list>

<union
 id =ID
 memberTypes = List ofQName
 {any attributes with non-schema namespace . . .}>
 Content:(annotation?,simpleType*)
</union>

The<simpleType> element and its descendantsnormally, when there are no errors, map to aSimple Type Definition component. The case in which anunknown facet is used in the definition of a simple typedefinition is handled specially: the<simpleType> in question is not in error, but it does not map to any component at all.

Note: The effect of the special handling ofunknown facets is to ensure (1) that·implementation-defined· facets which are not supported by a particular implementation result in the types which depend upon themnot being present in the schema, and (2) that the presence of references tounknown facets in a schema document does not preventthe rest of the schema document being processed and used.

The following subsections define one set of common mappingrules for simple type definitions, and three specializedsets of mapping rules for atomic, list, and union datatypes,respectively.

If the<simpleType> elementhas a<restriction> element among its children,and the base type definition has{variety} =atomic, then the mapping rules inCommon mapping rules for Simple Type Definitions (§3.16.2.1)andMapping Rules for Atomic Simple Type Definitions (§3.16.2.2)apply.
If the<simpleType> elementhas a<list> element among its children,or if it has a<restriction> childand the base type definition has{variety} =list, then the mapping rules inCommon mapping rules for Simple Type Definitions (§3.16.2.1)andMapping Rules for Lists (§3.16.2.3)apply.
If the<simpleType> elementhas a<union> element among its children,or if it has a<restriction> childand the base type definition has{variety} =union, then the mapping rules inCommon mapping rules for Simple Type Definitions (§3.16.2.1)andMapping Rules for Unions (§3.16.2.4)apply.

3.16.2.1 Common mapping rules for Simple Type Definitions

The following rules apply to all simple type definitions.

XML Mapping Summary forSimple Type DefinitionSchema Component

Property

Representation

The·actual value· of thename[attribute] if present on the<simpleType> element, otherwise·absent·.

The·actual value· of thetargetNamespace[attribute] of the ancestor<schema> element information item if present, otherwise·absent·.

The appropriatecase among the following:

1Ifthe<restriction> alternative is chosen,thenthe type definition·resolved· to by the·actual value· of thebase[attribute] of<restriction>, if present, otherwise thetype definition corresponding to the<simpleType> amongthe[children] of<restriction>.

2Ifthe<list> or<union> alternative is chosen,then·xs:anySimpleType·.

A subset of{restriction,extension,list,union}, determined as follows.[Definition:] LetFS bethe·actual value· of thefinal[attribute], if present, otherwise the·actual value· of thefinalDefault[attribute] of the ancestorschema element, if present, otherwise the empty string. Then the property value isthe appropriatecase among the following:

1If·FS· is the empty string,thenthe empty set;

2If·FS· is "#all",then{restriction,extension,list,union};

3otherwiseConsider·FS· asa space-separated list, and includerestriction if"restriction" is in that list, and similarly forextension,list andunion.

The appropriatecase among the following:

1Ifthename[attribute] is present,then·absent·

2otherwise the appropriatecase among the following:

2.1Ifthe parent element information item is<attribute>,thenthe correspondingAttribute Declaration

2.2Ifthe parent element information item is<element>,thenthe correspondingElement Declaration

2.3Ifthe parent element information item is<list> or<union>,thentheSimple Type Definitioncorresponding to the grandparent<simpleType> element information item

2.4Ifthe parent element information item is<alternative>,then theElement Declaration corresponding to the nearest enclosing<element> element information item

2.5otherwise(the parent element information item is<restriction>), the appropriatecase among the following:

2.5.1Ifthe grandparent element information item is<simpleType>,thentheSimple Type Definitioncorresponding to the grandparent

2.5.2otherwise(the grandparent element information item is<simpleContent>), theSimple Type Definition which is the{content type}.{simple type definition} of theComplex Type Definition corresponding to the great-grandparent<complexType> element information item.

If the<list> alternative is chosen,thenlist, otherwise if the<union> alternative ischosen, thenunion, otherwise (the<restriction>alternative is chosen), then the{variety}of the{base type definition}.

The appropriatecase among the following:

1Ifthe<restriction> alternative is chosenand the children of the<restriction> element are alleither<simpleType> elements,<annotation> elements, or elements which specify constraining facets supported by the processor,then the set ofConstraining Facet componentsobtained by·overlaying· the{facets} of the{base type definition} with theset ofConstraining Facet componentscorresponding to those[children] of<restriction> which specify facets, as defined inSimple Type Restriction (Facets) (§3.16.6.4).

2Ifthe<restriction> alternative is chosenandthe children of the<restriction> elementinclude at least one element of which the processor has noprior knowledge (i.e. not a<simpleType> element,an<annotation> element, or an elementdenoting a constraining facet known to and supported by the processor),thenthe<simpleType> elementmaps to no component at all (but is not in error solely on account ofthe presence of the unknown element).

3Ifthe<list> alternative is chosen,thena set with one member, awhiteSpace facet with{value} =collapse and{fixed} =true.

4otherwisethe empty set

Based on{variety},{facets},{base type definition} and{member type definitions}, a set ofFundamental Facet components, oneeach as specified inThe ordered Schema Component,The bounded Schema Component,The cardinality Schema Component andThe numeric Schema Component.

The·annotation mapping· of the set of elements containing the<simpleType>, and one of the<restriction>,<list> or<union>[children], whichever is present, as defined inXML Representation of Annotation Schema Components (§3.15.2).

3.16.2.2 Mapping Rules for Atomic Simple Type Definitions

The following rule applies if the{variety} isatomic

[Definition:] Theancestors of a·type definition· are its{base type definition} and the·ancestors· of its{base type definition}.(The ancestors of aSimple Type DefinitionT in the type hierarchy are themselves·type definitions·; they are distinct fromthe XML elements which may be ancestors, in the XML documenthierarchy, of the<simpleType> element which declaresT.)

XML Mapping Summary forAtomic Simple Type DefinitionSchema Component

Property

Representation

From among the·ancestors· of thisSimple Type Definition, thatSimple Type Definition which corresponds to aprimitive datatype.

3.16.2.3 Mapping Rules for Lists

If the{variety} islist, the following additionalproperty mapping applies:

XML Mapping Summary forList Simple Type DefinitionSchema Component

Property

Representation

The appropriatecase among the following:

1Ifthe{base type definition} is·xs:anySimpleType·,thentheSimple Type Definition (a)·resolved· to by the·actual value· of theitemType[attribute] of<list>,or (b), corresponding to the<simpleType> amongthe[children] of<list>, whichever is present.

Note: Inthis case, a<list> element will invariably be present; it willinvariably have either anitemType[attribute] or a<simpleType>[child], but not both.

2otherwise(that is, the{base type definition} is not·xs:anySimpleType·), the{item type definition} of the{base type definition}.

Note: In this case, a<restriction> element will invariablybe present.

3.16.2.4 Mapping Rules for Unions

If the{variety} isunion, the followingadditional property mapping applies:

XML Mapping Summary forUnion Simple Type DefinitionSchema Component

Property

Representation

Simple Type Definition of anySimpleType

The appropriatecase among the following:

1Ifthe{base type definition} is·xs:anySimpleType·,thenthe sequence ofSimple Type Definitions (a)·resolved· to by the items in the·actual value· of thememberTypes[attribute] of<union>,if any, and (b) corresponding to the<simpleType>s amongthe[children] of<union>, if any, in order.

Note: Inthis case, a<union> element will invariably be present; it willinvariably have either amemberTypes[attribute] or one or more<simpleType>[children], or both.

2otherwise(that is, the{base type definition} is not·xs:anySimpleType·), the{member type definitions} of the{base type definition}.

Note: In this case, a<restriction> element will invariablybe present.

3.16.3 Constraints on XML Representations of Simple Type Definitions

Schema Representation Constraint: Simple Type Definition Representation OK

In addition to the conditions imposed on<simpleType> element information items by the schema for schema documents,all of the followingmust be true:

1 No two elements among the[children] of<restriction> have the sameexpanded name in the Schema (xs) namespace, unless thatexpanded name is one ofxs:enumeration,xs:pattern, orxs:assertion.

Note: That is, most of the facets for simple types defined by this specification are forbidden to occur more than once. But<enumeration>,<pattern>, and<assertion> may occur multiple times, and facets defined in other namespaces and made available as extensions to this specification may occur multiple times.

2If the<restriction> alternative is chosen, it has either abase[attribute] or a<simpleType> among its[children], but notboth.

3If the<list> alternative is chosen, it has either anitemType[attribute] or a<simpleType> among its[children],but not both.

4If the<union> alternative is chosen, either ithas a non-emptymemberTypes[attribute] or ithas at least onesimpleType[child].

3.16.4 Simple Type Definition Validation Rules

Validation Rule: String Valid

For a stringS to be locally·valid· with respect to a simple type definitionTall of the followingmust be true:

1The·normalized value· ofS,N, is calculated using thewhiteSpace facet, and any otherpre-lexical facets associated withT, as described in the definition of the term "·normalized value·".

2N is schema-valid with respect toT as defined byDatatype Valid in[XML Schema: Datatypes].

3LetV be the·actual value· ofN with respect toT. Then:

Every·ENTITY value· inV is a·declared entity name·.

[Definition:] When a stringN is schema-valid with respect to a simple type definitionT as defined byDatatype Valid with the corresponding·actual value·V,

1 Thevalidating type ofV isT ifT is not a union type, otherwise the validating type is thebasic member ofT'stransitive membership which actually·validated·N.

2 If the·validating type· ofV is a list typeL and the{item type definition} ofL isI, then thevalidating type of an (atomic) item valueA occurring inV isI ifI is not a union type, otherwise the validating type is thebasic member ofI'stransitive membership which actually·validated· the substring inN that corresponds toA.

[Definition:] When the·validating type· of an·actual value· is or is·derived· from a simple type definitionT, the value is also referred to as aT value. For example, anENTITY value is an·actual value· whose·validating type· is or is derived from the built-in simple type definitionENTITY, and anID value is one whose·validating type· is or is derived fromID.

[Definition:] A string is adeclared entity name if and only if it is equal to the[name] of some unparsed entity information item in the value of the[unparsedEntities] property of the document information item at the root of the infoset containing the element or attribute information item whose·normalized value· the string is.

3.16.5 Simple Type Definition Information SetContributions

None as such.

3.16.6 Constraints on Simple Type Definition Schema Components

3.16.6.1 Simple Type Definition Properties Correct

All simple type definitionsmust satisfy both the following constraints.

Schema Component Constraint: Simple Type Definition Properties Correct

All of the followingmust be true:

1The values of the properties of a simple type definition are as described in the property tableau inThe Simple Type Definition Schema Component, modulo the impact ofMissing Sub-components (§5.3).

2All simple type definitions are, or are·derived· ultimately from,·xs:anySimpleType· (so circular definitions are disallowed). That is, it is possible to reach a primitive datatype or·xs:anySimpleType· by following the{base type definition} zero or more times.

3The{final} of the{base type definition} does not containrestriction.

4There is not more than one member of{facets} of the same kind.

5Each member of{facets} is supported by the processor.

Note: As specified normatively elsewhere, all conforming processorsmust support the facets defined by[XML Schema: Datatypes]; support for additional facets is·implementation-defined·. If a schema document applies anunknown facet, the immediate result will be a violation of this constraint, so that the simple type defined by means of that facet will be excluded from the schema, and any references to it will be treated as undischarged references.

3.16.6.2 Derivation Valid (Restriction, Simple)

Schema Component Constraint: Derivation Valid (Restriction, Simple)

For anySimple Type DefinitionD whose{base type definition} is someSimple Type DefinitionB,the appropriatecase among the followingmust be true:

1IfD.{variety} =atomic,thenall of the following are true:

1.1EitherD is·xs:anyAtomicType·, or elseB is an atomic simple type definition.

Note: The type·xs:anyAtomicType· is an exception because its{base type definition} is·xs:anySimpleType·, whose{variety} is·absent·.

1.2B.{final} does not containrestriction.

1.3 For each facet inD.{facets} (call thisDF)all of the following are true:

1.3.1DF is applicable toD, as specified inApplicable Facets of[XML Schema: Datatypes].

1.3.2DF satisfies the constraints on facet components given in the appropriate subsection ofConstraining Facets in[XML Schema: Datatypes].

2IfD.{variety} =list,thenall of the following are true:

2.1D.{item type definition} is not a special type definition and eitherD.{item type definition}.{variety} =atomic orD.{item type definition}.{variety} =union and there are no types whose{variety} islist among the union'stransitivemembership.

2.2 The appropriatecase among the following is true:

2.2.1IfBis·xs:anySimpleType· ,thenall of the following are true:

2.2.1.1D.{item type definition}.{final} does not containlist.

2.2.1.2D.{facets} contains only thewhiteSpace facet component with{value} =collapse and{fixed} =true.

2.2.2otherwiseall of the following are true:

2.2.2.1B.{variety} =list.

2.2.2.2B.{final} does not containrestriction.

2.2.2.3D.{item type definition} is validly·derived· fromB.{item type definition}, as defined inType Derivation OK (Simple) (§3.16.6.3).

2.2.2.4All facets in{facets} are applicable toD, as specified inApplicable Facets.

2.2.2.5All facets in{facets} satisfy the constraints on facet components given in the appropriate subsection ofConstraining Facets.

The first case above will apply when a list isconstructed by specifying an item type, the second when·derived· by restriction from another list.

3IfD.{variety} isunion,thenall of the following are true:

3.1D.{member type definitions} does not contain a special type definition.

3.2 The appropriatecase among the following is true:

3.2.1IfB is·xs:anySimpleType· ,thenall of the following are true:

3.2.1.1All of the{member type definitions} have a{final} which does not containunion.

3.2.1.2D.{facets} is empty.

3.2.2otherwiseall of the following are true:

3.2.2.1B.{variety} =union.

3.2.2.2B.{final} does not containrestriction.

3.2.2.3Each type definition inD.{member type definitions} is validly·derived· from the corresponding type definition inB.{member type definitions}, as defined inType Derivation OK (Simple) (§3.16.6.3).

3.2.2.4All facets in{facets} are applicable toD, as specified inApplicable Facets.

3.2.2.5All facets in{facets} satisfy the constraints on facet components given in the appropriate subsection ofConstraining Facets.

The first case above will apply when a union isconstructed by specifying one or more member types, the secondwhen·derived· by restriction from another union.

3.3NeitherD nor any type·derived· from it is a member of itsowntransitive membership.

[Definition:] Asimple type definitionT is avalid restriction of its{base type definition}if and only ifT satisfies constraintDerivation Valid (Restriction, Simple) (§3.16.6.2).

3.16.6.3 Type Derivation OK (Simple)

The following constraint defines relations appealed to elsewhere inthis specification.

Schema Component Constraint: Type Derivation OK (Simple)

For a simple type definition (call itD, for·derived·) to be validly·derived· from a type definition (call thisB, for base) subject to a set of blocking keywordsdrawn from the set {extension,restriction,list,union} (of which onlyrestriction is actually relevant; call this setS)one of the followingmust be true:

1They are the same type definition.

2All of the following are true:

2.1restriction is not inS, or inD.{base type definition}.{final};

2.2One or more of the following is true:

2.2.1D.{base type definition} =B.

2.2.2D.{base type definition} is not·xs:anyType· and is validly·derived· fromBgivenS,as defined by this constraint.

2.2.3D.{variety} =list orunion andB is·xs:anySimpleType·.

2.2.4All of the following are true:

2.2.4.1B.{variety} =union.

2.2.4.2D is validly·derived· from a type definitionM inB'stransitivemembership givenS, as defined by thisconstraint.

2.2.4.3The{facets} property ofBand of anyinterveningunion datatypes is empty.

Note: It is a consequence of this requirement that thevalue space,lexical space, andlexicalmapping ofD will be subsets of those ofB.

Note: With respect to clause1, see the Note on identity atthe end of (§3.4.6.5) above.

Note: When a simple type definitionS is said to be "validly·derived·" from a type definitionT,without mention of any specific set of blocking keywords,then what is meant is thatS is validly derived fromT, subject to the empty set of blocking keywords,i.e. without any particular limitations.

Note: It is a consequence of clause2.2.4 thatthe constraint (§3.16.6.2) can hold betweenaSimple Type Definition in thetransitive membership of a union type, and the union type,even though neither is actually·derived· from the other. The slightly misleading terminology is retained for historical reasonsand for compatibility with version 1.0 of this specification.

3.16.6.4 Simple Type Restriction (Facets)

Schema Component Constraint: Simple Type Restriction (Facets)

For a simple type definition (call itR) to restrict another simple typedefinition (call itB) with aset of facets (call thisS)all of the followingmust be true:

1The{variety} ofR is the same as that ofB.

2If{variety} isatomic, the{primitive type definition} ofR is the same as that ofB.

3The{facets} ofR are the{facets} ofB·overlaid· withS.

Additional constraint(s) sometimes apply depending on the kind of facet, see the appropriate sub-section of4.3 Constraining Facets.

[Definition:] Given two sets of facetsB andS, the result ofoverlayingB withS is the set of facetsR for whichall of the following are true:

1Every facet inS is inR.

2Every facet inB is inR,unlessit is of the same kind as somefacet inS,in which case it is not included inR.

3Every facet inR is required by clause1or clause2 above.

3.16.7 Built-in Simple Type Definitions

3.16.7.1`xs:anySimpleType`

TheSimple Type Definition ofanySimpleTypeispresent in every schema. It has the following properties:

Property

Value

'anySimpleType'

'http://www.w3.org/2001/XMLSchema'

The empty set

The empty set

The empty set

Simple Type Definition of anyAtomicType

The empty sequence

The definitionof·xs:anySimpleType· is the root of the simple type definition hierarchy, and as such mediates between the other simple type definitions, which all eventually trace back to it via their{base type definition} properties, and·xs:anyType·, which isits{base type definition}.

3.16.7.2`xs:anyAtomicType`

TheSimple Type Definition ofanyAtomicTypeis present in every schema. It has the following properties:

Property

Value

'anyAtomicType'

'http://www.w3.org/2001/XMLSchema'

The empty set

The empty set

The empty set

atomic

Simple Type Definition ofxs:error

The empty sequence

3.16.7.3`xs:error`

ASimple Type Definition for·xs:error· is present in every schema by definition. It has the following properties:

Property

Value

'error'

'http://www.w3.org/2001/XMLSchema'

{extension,restriction,list,union}

The empty set

The empty set

union

The empty sequence

Simple Type Definition corresponding to the built-in primitive datatypes

The empty sequence

Note: The datatypexs:error has no valid instances(i.e. it has an empty value space and an empty lexical space).This is a natural consequence of its construction: a value isa value of a union type if and only if it is a value of atleast one member of the{member type definitions} of the union. Sincexs:error hasno member type definitions, there can be no values which arevalues of at least one of its member types. And since the valuespace is empty, the lexical space is also empty.

The typexs:error is expected to be usedmostly in conditional type assignment. Whenever it serves as the·governing· type definition for an attribute or element informationitem, that item will be invalid.

3.16.7.4 Built-in primitive datatypes

Simple type definitions corresponding to all the built-in primitive datatypes, namelystring,boolean,float,double,decimal,dateTime,duration,time,date,gMonth,gMonthDay,gDay,gYear,gYearMonth,hexBinary,base64Binary,anyURI,QName andNOTATION (see thePrimitiveDatatypes section of[XML Schema: Datatypes]) are present by definition in every schemaas follows:

Property

Value

[as appropriate]

'http://www.w3.org/2001/XMLSchema'

·xs:anyAtomicType·

The empty set

atomic

[this simple typedefinition itself]

{awhitespace facet with[value] =collapse and[fixed] =true in all cases exceptstring, which has[value] =preserve and[fixed] =false}

[as appropriate]

Simple Type Definition corresponding to the built-in ordinary datatypes

The empty sequence

All conforming implementations of this specificationmust support all the primitive datatypes defined in[XML Schema: Datatypes]. It is·implementation-defined· whether additional primitive datatypes are supported, and whether, if so, they are automatically incorporated in every schema or not. If·implementation-defined· primitives are supported, the implementationmust satisfy the rules for·implementation-defined· primitive datatypes described in[XML Schema: Datatypes].

[Definition:] A type about which a processor possesses prior knowledge, and which the processor can support without any declaration of thetype being supplied by the user, is said to beautomatically knownto the processor.

Note: By their nature, primitive types can be supported by aprocessor only if·automatically known· to that processor.

Types·automatically known· to a processor, whether primitive orderived, can be included automatically by that processor inall schemas, but need not be. It is possible, for example,for a processor to have built-in prior knowledge of a set ofprimitive and derived types, but to include them in the schemaonly when the relevant namespace is explicitly imported, or agiven run-time option is selected, or on some otherconditions; such conditions are not defined by thisspecification.

Note: The definition of "·automatically known·" is not intended to prevent implementations from allowing usersto specify new primitive types.If an implementation defines a mechanism by which users candefine or supply an implementation of a primitive type, thenwhen those mechanisms are successfully used, such user-suppliedtypes are·automatically known· to the implementation, as that term isused in this specification.

3.16.7.5 Other built-in datatypes

Similarly, simple type definitions corresponding to all the other built-in datatypes (see theOther Built-in Datatypes sectionof[XML Schema: Datatypes]) are present by definition inevery schema, with properties as specified in[XML Schema: Datatypes] and asrepresented in XML inIllustrative XML representations for the built-in ordinary type definitions.

Property

Value

[as appropriate]

'http://www.w3.org/2001/XMLSchema'

[as specified in the appropriatesub-section ofOther Built-in Datatypes]

The empty set

[atomic orlist, as specified in the appropriatesub-section ofOther Built-in Datatypes]

[if{variety} isatomic, then the{primitive type definition} of the{base type definition}, otherwise·absent·]

[as specified in the appropriatesub-section ofOther Built-in Datatypes]

[as specified in the appropriatesub-section ofOther Built-in Datatypes]

if{variety} isatomic, then·absent·, otherwise as specified in the appropriatesub-section ofOther Built-in Datatypes]

{attribute group definitions}

As shown in the XML representationsof the ordinary built-in datatypes inIllustrative XML representations for the built-in ordinary type definitions

All conforming implementations of this specificationmust support all the built-in datatypes defined in[XML Schema: Datatypes]. It is·implementation-defined· whether additional derived types are·automatically known· to the implementation without declaration and whether, if so, they are automatically incorporated in every schema or not.

3.17 Schemas as a Whole

        3.17.1The Schema Itself
        3.17.2XML Representations of Schemas
            3.17.2.1References to Schema Components
            3.17.2.2References to Schema Components from Elsewhere
        3.17.3Constraints on XML Representations of Schemas
        3.17.4Validation Rules for Schemas as a Whole
        3.17.5Schema Information Set Contributions
            3.17.5.1Schema Information
            3.17.5.2ID/IDREF Table
        3.17.6Constraints on Schemas as a Whole
            3.17.6.1Schema Properties Correct
            3.17.6.2QName resolution (Schema Document)
            3.17.6.3QName 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.

3.17.1 The Schema Itself

At the abstract level, the schema itself is just a containerfor its components.

Schema Component:Schema, a kind ofAnnotated Component

{annotations}

A sequence ofAnnotation components.

{type definitions}

A set ofType Definition components.

{attribute declarations}

A set ofAttribute Declaration components.

{element declarations}

A set ofElement Declaration components.

{attribute group definitions}

A set ofAttribute Group Definition components.

{model group definitions}

A set ofModel Group Definition components.

{notation declarations}

A set ofNotation Declaration components.

{identity-constraint definitions}

A set ofIdentity-Constraint Definition components.

3.17.2 XML Representations of Schemas

A schema is represented in XML by one or more·schema documents·, that is, one or more<schema> element information items. A·schema document· contains representations for a collection of schema components, e.g. type definitions and element declarations, which have a common{target namespace}. A·schema document· which has one or more<import> element information items corresponds to a schema with components with more than one{target namespace}, seeImport Constraints and Semantics (§4.2.6.2).

As always, the mapping rules given in this section apply after, not before, the appropriate·pre-processing·.

XML Representation Summary:schema Element Information Item et al.

<schema
 attributeFormDefault = (qualified |unqualified) : unqualified
 blockDefault = (#all | List of (extension |restriction |substitution)) : ''
 defaultAttributes =QName
 xpathDefaultNamespace = (anyURI | (##defaultNamespace |##targetNamespace |##local)) : ##local
 elementFormDefault = (qualified |unqualified) : unqualified
 finalDefault = (#all | List of (extension |restriction |list |union)) : ''
 id =ID
 targetNamespace =anyURI
 version =token
 xml:lang =language
 {any attributes with non-schema namespace . . .}>
 Content:((include |import |redefine |override |annotation)*, (defaultOpenContent,annotation*)?, ((simpleType |complexType |group |attributeGroup |element |attribute |notation),annotation*)*)
</schema>

<defaultOpenContent
 appliesToEmpty =boolean : false
 id =ID
 mode = (interleave |suffix) : interleave
 {any attributes with non-schema namespace . . .}>
 Content:(annotation?,any)
</defaultOpenContent>

The<schema> element information item maps to aSchema component as follows.

XML Mapping Summary forSchemaSchema Component

Property

Representation

{type definitions}

The simple and complex type definitions corresponding to all the<simpleType> and<complexType> element information items in the[children], if any, plus any definitions brought in via<include> (seeAssembling a schema for a single target namespace from multiple schema definition documents (<include>) (§4.2.3)),<override> (seeOverriding component definitions (<override>) (§4.2.5)),<redefine> (seeIncluding modified component definitions (<redefine>) (§4.2.4)), and<import> (seeReferences to schema components across namespaces (<import>) (§4.2.6)).

{attribute declarations}

The (top-level) attribute declarations corresponding to all the<attribute> element information items in the[children], if any, plus any declarations brought in via<include>,<override>,<redefine>, and<import>.

{element declarations}

The (top-level) element declarations corresponding to all the<element> element information items in the[children], if any, plus any declarations brought in via<include>,<override>,<redefine>, and<import>.

The attribute group definitionscorresponding to all the<attributeGroup> element information items in the[children], if any, plus any definitions brought in via<include>,<override>,<redefine>, and<import>.

{model group definitions}

The model group definitionscorresponding to all the<group> element information items in the[children], if any, plus any definitions brought in via<include>,<redefine> and<import>.

{notation declarations}

The notation declarationscorresponding to all the<notation> element information items in the[children], if any, plus any declarations brought in via<include>,<override>,<redefine>, and<import>.

{identity- constraint definitions}

The identity-constraint definitions corresponding to all the<key>,<keyref>, and<unique> element information items anywhere within the[children], if any, plus any definitions brought in via<include>,<override>,<redefine>, and<import>.

[local name],[namespace name],[normalized value],[prefix],[attribute type],[owner element]

The·annotation mapping· of the set of elements containing the<schema> and all the<include>,<redefine>,<override>,<import>, and<defaultOpenContent>[children], if any, as defined inXML Representation of Annotation Schema Components (§3.15.2).

Note that none of the attribute information items displayed above correspond directly to properties of schemas. TheblockDefault,finalDefault,attributeFormDefault,elementFormDefault andtargetNamespace attributes are appealed to in the sub-sections above, as they provide global information applicable to many representation/component correspondences. The other attributes (id andversion) are for user convenience, and this specification defines no semantics for them.

The definition of the schema abstract data model inXSD Abstract Data Model (§2.2) makes clear that most components have a{target namespace}. Most components corresponding to representations within a given<schema> element information item will have a{target namespace} which corresponds to thetargetNamespace attribute.

Since the empty string is not a legal namespace name, supplying an empty string fortargetNamespace is incoherent, and isnot the same as not specifying it at all. The appropriate form of schema document corresponding to a·schema· whose components have no{target namespace} is one which has notargetNamespace attribute specified at all.

Note:[XML Namespaces 1.1] discusses only instance document syntax forelements and attributes; it therefore provides no direct framework for managingthe names of type definitions, attribute group definitions, and so on.Nevertheless, the specification applies the target namespace facility uniformly to allschema components, i.e. not only declarations but also definitions have a{target namespace}.

Although the example schema at the beginning of this section might be a complete XML document,<schema>need not be the document element, but can appear within other documents.Indeed there is no requirement that a schema correspond to a (text) documentat all: it could correspond to an element information item constructed 'byhand', for instance via a DOM-conformant API.

Aside from<include> and<import>,which do not correspond directly to any schema component at all, eachof the element information items whichmay appear in the contentof<schema>corresponds to a schema component, and all except<annotation> arenamed. The sections below present each such item in turn, setting outthe components to which it corresponds.

3.17.2.1 References to Schema Components

Reference to schema components from a schema document is managed ina uniform way, whether the component corresponds to an elementinformation item from the same schema document or is imported(References to schema components across namespaces (<import>) (§4.2.6)) from an external schema(whichmay, but need not, correspond to an actual schemadocument). The form of all such references is a·QName·.

[Definition:] AQName is aname with an optional namespace qualification, as defined in[XML Namespaces 1.1]. When used in connection with the XMLrepresentation of schema components or references to them, this refersto the simple typeQNameas defined in[XML Schema: Datatypes].For brevity, the term·QName·is also used to refer to·actual values· in the value space of theQName simple type, which areexpanded names with a[Definition:] local nameand a[Definition:] namespace name.

[Definition:] AnNCName isa name with no colon, as defined in[XML Namespaces 1.1]. When used in connection with the XMLrepresentation of schema components in this specification, this refersto the simple typeNCName as defined in[XML Schema: Datatypes].

Note: It is·implementation-defined· whether aschema processor supports the definitions ofQName andNCName found in[XML Namespaces 1.1] or those found in[Namespaces in XML 1.0] or both.

[Definition:] A·QName· in a schema documentresolves to a component in a schema if and only if in the context of that schema the QName and the component together satisfy the ruleQName resolution (Schema Document) (§3.17.6.2). A·QName· in an input document, or a pair consisting of a local name and a namespace name,resolves to a component in a schema if and only if in the context of that schema the QName (or the name + namespace pair) and the component together satisfy the ruleQName resolution (Instance) (§3.17.6.3).

In each of the XMLrepresentation expositions in the following sections, an attribute is shown ashaving typeQName if and only if it isinterpreted as referencing a schema component.

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 referenceto a typedefinition corresponding to a<complexType> element information itemlocated elsewhere in the schema document, the other two refer to typedefinitions from schemas for other namespaces and assume that their namespaceshave been declared for import. SeeReferences to schema components across namespaces (<import>) (§4.2.6) for a discussion of importing.

3.17.2.2 References to Schema Components from Elsewhere

The names of schema components such as type definitions and elementdeclarations are not of typeID: they are notunique within a schema, just within a symbol space. This means that simplefragment identifiers using these nameswill not work to reference schema components from outsidethe context of schema documents.

The preferred way to refer to schema components is to use[XML Schema: Component Designators], which defines a mechanism to designate schema components using thexscd()[XPointer] scheme.

Alternatively, references to specificelement information items in the schema document can be interpreted as to theircorresponding schema documents. This can be done using mechanisms supported by[XPointer], for example, by using shorthand pointers.It is a matter for applications to specify whether they interpretthesereferences as being to the relevant element information item (i.e. withoutspecial recognition of the relation of schema documents to schema components) or as being to thecorresponding schema component.

3.17.3 Constraints on XML Representations of Schemas

None as such.

3.17.4 Validation Rules for Schemas as a Whole

None as such.

3.17.5 Schema Information Set Contributions

3.17.5.1 Schema Information

Schema Information Set Contribution: Schema Information

Schema components provide a wealth of information about thebasis of·assessment·, which can often be useful for subsequentprocessing. Reflecting component structure into a form suitable forinclusion in the·post-schema-validation infoset· is the way this specification provides formaking this information available.

Accordingly,[Definition:] by anitem isomorphic to a component is meantan information item whose type is equivalent to the component's, withone property per property of the component, with the same name, andvalue either the same atomic value, or an information itemcorresponding in the same way to its component value, recursively, asnecessary.

The·validation root·has the following properties:

PSVI Contributions for element or attribute information items

[schema information]

Aset ofnamespace schema information informationitems, one for each namespace name which appears as the{target namespace} of any schema component in theschema used for that assessment, and one for·absent· if any schema component in the schemahad no{target namespace}. Eachnamespace schema information information item has thefollowing properties and values:

PSVI Contributions for namespace schema information information items

[schema namespace]

Anamespace name or·absent·.

[schema components]

A (possibly empty) set of schema component informationitems, each one an·item isomorphic· toa component whose{target namespace} isthe sibling[schema namespace] property above, drawn fromthe schema used for·assessment·.

[schema documents]

A(possibly empty) set ofschema document informationitems, with properties and values as follows, for each schema documentwhich contributed components to the schema, and whosetargetNamespace matches the sibling[schema namespace] property above (or whosetargetNamespace was·absent· but that contributed components tothat namespace by being<include>d by a schema document with thattargetNamespace as perAssembling a schema for a single target namespace from multiple schema definition documents (<include>) (§4.2.3)):

PSVI Contributions for schema document information items

[document location]: Either a URI reference, if available,otherwise·absent·
[document]: A documentinformation item, if available, otherwise·absent·.

The[schema components] property is provided forprocessors which wish to provide a single access point to thecomponents of the schema which was used during·assessment·. Lightweight processors are free to leave it empty, but if itis provided, itmust contain at a minimum all the top-level (i.e. named) components which actually figured in the·assessment·, either directly or (because an anonymous component which figured is contained within) indirectly.

3.17.5.2 ID/IDREF Table

Schema Information Set Contribution: ID/IDREF Table

In the·post-schema-validation infoset· a set ofID/IDREF binding information items is associated with the·validation root·:

PSVI Contributions for element information items

[ID/IDREF table]: A (possibly empty) set ofID/IDREF binding information items, as specified below.

[Definition:] Let theeligible item set be the set consisting of every attribute or elementinformation item for whichall of the following are true:

1its[validation context] is the·validation root·;

2 its[schema actual value] is not·absent·;

3 its·governing· type definition is the built-in simple type definition forID,IDREF, orIDREFS, or a type definition·derived· or·constructed· directly (in a single derivation step) or indirectly (through one or more steps) from any of these.

Note: The use of[schema actual value]in the definition of·eligible item set· above means thatdefault orfixed value constraintsmay play apart in the·eligible item set·.

Note: Element information items that have complex types with simple contentcan appear in the·eligible item set·.

Then there is oneID/IDREF binding in the[ID/IDREF table] for every distinct string which is an·ID value· or an·IDREF value· in the·actual value· of a member of the·eligible item set·.

EachID/IDREF binding has properties as follows:

PSVI Contributions for ID/IDREF binding information items

[id]: The string identified above.
[binding]: A set consisting of every element information item for whichall of the following are true:
1its[validation context] is the·validation root·;
2it has an attribute information item inits[attributes] or an element information item in its[children] whose·actual value· is or contains the[id] ofthisID/IDREF binding and the corresponding type definition is or is·derived· fromID.

The net effect of the above is to have one entry for every string used as anid, whether by declaration or by reference, associated with those elements, ifany, which actually purport to have that id. SeeValidation Root Valid (ID/IDREF) (§3.3.4.5) abovefor the validation rule which actually checks for errors here.

Note: TheID/IDREF bindinginformation item, unlike most other aspects of thisspecification, is essentially an internal bookkeeping mechanism. It is introduced tosupport the definition ofValidation Root Valid (ID/IDREF) (§3.3.4.5) above.

3.17.6 Constraints on Schemas as a Whole

3.17.6.1 Schema Properties Correct

All schemas (seeSchemas as a Whole (§3.17))must satisfy the following constraint.

Schema Component Constraint: Schema Properties Correct

All of the followingmust be true:

1The values of the properties of a schema are as described inthe property tableau inThe Schema Itself (§3.17.1), modulo the impact ofMissing Sub-components (§5.3);

2None of the{type definitions},{attribute declarations},{element declarations},{attribute group definitions},{model group definitions},{notation declarations}, or{identity-constraint definitions} properties contains two or more schema components with the sameexpanded name.

3.17.6.2 QName resolution (Schema Document)

Schema Representation Constraint: QName resolution (Schema Document)

For a·QName· to resolve to a schema component of a specified kindall of the followingmust be true:

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·QName· appears, that is the appropriatecase among the following is true:

1.1Ifthe kind specified is simple or complex type definition,thenthe property is the{type definitions}.

1.2Ifthe kind specified is attribute declaration,thenthe property is the{attribute declarations}.

1.3Ifthe kind specified is element declaration,thenthe property is the{element declarations}.

1.4Ifthe kind specified is attribute group,thenthe property is the{attribute group definitions}.

1.5Ifthe kind specified is model group,thenthe property is the{model group definitions}.

1.6Ifthe kind specified is notation declaration,thenthe property is the{notation declarations}.

1.7Ifthe kind specified is identity-constraint definition,thenthe property is the{identity-constraint definitions}.

2The component's{name} matches the·local name· of the·QName·;

3The component's{target namespace} is identical to the·namespace name· of the·QName·;

4The appropriatecase among the following is true:

4.1Ifthe·namespace name· of the·QName· is·absent·,thenone of the following is true

4.1.1The<schema> element information item of the schema document containing the·QName· has notargetNamespace[attribute].

4.1.2The<schema> element information item of the that schema document contains an<import> element information item with nonamespace[attribute].

4.2otherwise the·namespace name· of the·QName· is the same asone of the following:

4.2.1The·actual value· of thetargetNamespace[attribute] of the<schema> element information item of the schema document containing the·QName·.

4.2.2The·actual value· of thenamespace[attribute] of some<import> element information item contained in the<schema> element information item of that schema document.

4.2.3http://www.w3.org/2001/XMLSchema.

4.2.4http://www.w3.org/2001/XMLSchema-instance.

3.17.6.3 QName resolution (Instance)

As the discussion above atSchema Component Details (§3) makes clear, at the level of schema components and·validation·, reference to components by name is normally not involved. In afew cases, however, qualified names appearing in information items being·validated·must be resolved to schema components by such lookup. The followingconstraint is appealed to in these cases.

Validation Rule: QName resolution (Instance)

A pair of a local name and a namespace name (or·absent·)resolve to a schema component of a specified kind in the context of·validation· by appeal to the appropriateproperty of the schema being used for the·assessment·. Each such property indexes components by name. The property to use is determined by the kind of component specified, that is, the appropriatecase among the followingmust be true:

1Ifthe kind specified is simple or complex type definition,thenthe property is the{type definitions}.

2Ifthe kind specified is attribute declaration,thenthe property is the{attribute declarations}.

3Ifthe kind specified is element declaration,thenthe property is the{element declarations}.

4Ifthe kind specifiedis attribute group,thenthe property is the{attribute group definitions}.

5Ifthe kind specified ismodel group,thenthe property is the{model group definitions}.

6Ifthe kind specified is notation declaration,thenthe property is the{notation declarations}.

The component resolved to is the entry in the table whose{name} matches the local name of the pair and whose{target namespace} is identical to the namespace name of the pair.

4 Schemas and Namespaces: Access and Composition

This chapter defines the mechanisms by which this specification establishes the necessaryprecondition for·assessment·, namely access toone or more schemas. This chapter also sets out in detail the relationshipbetween schemas and namespaces, as well as mechanisms formodularization of schemas, including provision for incorporating definitionsand declarations from one schema in another, possibly with modifications.

Conformance (§2.4) describes three levels of conformance for schemaprocessors, andSchemas and Schema-validity Assessment (§5) provides a formal definition of·assessment·. This section sets outin detail the 3-layer architecture implied by the three conformance levels.The layersare:

The·assessment· core, relating schema components and instanceinformation items;
Schema representation: the connections between XMLrepresentations 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 componentscan be applied to in the·assessment· of an element information item. Layer 2 specifies the use of<schema>elements in XML documents as the standard XML representation forschema information in a broad range of computer systems and executionenvironments. To support interoperation over the World Wide Web in particular,layer 3 provides a set of conventions for schema reference on theWeb. Additional details on each of the three layers are provided in the sections below.

4.1 Layer 1: Summary of the Schema-validity Assessment Core

The fundamental purpose of the·assessment· core is to define·assessment· for a singleelement information item and its descendants, with respect to acomplex typedefinition. All processors are required to implement this core predicate in amanner which conforms exactly to this specification.

·Assessment· is defined with reference toan·XSD schema· (notenot a·schema document·).

As specified above, each schema component is associated directly orindirectly 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 orpre-compile) the entire schema prior to the start of an·assessment· episode, or togather the schema lazily as individual components are required. In allcases it is required that:

The processor succeed in locating the·schema components· transitively required to complete an·assessment· (note that components derivedfrom·schema documents· can be integratedwith components obtained through other means);
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·assessment· to differ from that which would have been obtained from the same schema components acquired in bulk.

Note: the·assessment· core is defined in terms of schema components at theabstract level, and no mention is made of the schema definitionsyntax (i.e.<schema>). Although many processors will acquireschemas in this format, othersmay operate on compiled representations, on aprogrammatic representation as exposed in some programming language, etc.

The obligation of a schema-aware processor as far as the·assessment·core is concerned is to implement one or more of the options for·assessment· given below inAssessing Schema-Validity (§5.2). Neither thechoice of element information item for that·assessment·, nor which of themeans of initiating·assessment· are used, is within the scope of this specification.

Although·assessment· is defined recursively, it is also intended to beimplementable in streamingprocessors. Such processorsmay choose to incrementally assemble the schema duringprocessing in response, for example, to encountering new namespaces. The implication of theinvariants expressed above is that such incremental assemblymustresult in an·assessment· outcome that is thesame as wouldbe given if·assessment· were undertaken againwith the final, fully assembled schema.

4.2 Layer 2: Schema Documents, Namespaces and Composition

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

The sub-sections ofSchema Component Details (§3) define anXML 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 toassemble a complete schema from multiple sources.

Note: The core·assessment·architecture requires that a complete schema with all the necessarydeclarations and definitions be available. This willsometimes involve resolving both instance → schema (or schema document)and schema-document → schema (or schema document) references. As observed earlier inConformance (§2.4), theprecise mechanisms for resolving such references are expected toevolve over time. In support of such evolution, this specificationobserves the design principle that references from one schema documentto a schema use mechanisms that directly parallel those used toreference 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 andinclude, with which it is closely associated.

4.2.1 Basic concepts of schema construction and composition

When a schema is assembled from multiple sources, those sources can include both·schema documents· and other sources of components. Several of the mechanisms described below allow a·schema document· to refer to a schema, either by giving the target namespace of its components, or indirectly, by referring to a·schema document· (and thus implicitly to the schema corresponding to that·schema document·).

The sections that follow appeal often to the following concepts.

pre-processing

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.

conditional-inclusion pre-processing

The process of applying to a schema document the filtering described in sectionConditional inclusion (§4.2.2). This pre-processing is usually assumed silently; when it is explicitly described, then for a·schema document·D, the result of conditional-inclusion pre-processing ofD is written "ci(D)".

immediate components

The immediate components of a·schema document·D are the components corresponding to its definition and declaration[children]; also written "immed(D)".

inter-schema-document references

The<include>,<redefine>,<override>, and<import> elements defined below.

corresponding schema

The schema corresponding to a given·schema document·D is the schema containing the built-in components, the·automatically known· components automatically included in the schema by the schema processor,·immed(D)·, and the components included by virtue of the inter-schema-document references included inD (for which see the rules below), and no other components. Also written "schema(D)".

target namespace

The target namespace specified in a schema documentD; also written "tns(D)".

chameleon pre-processing

The application, to a schema documentD, of the transformation specified inTransformation for Chameleon Inclusion (§F.1), with respect to some namespaceN, so as to convert it to useN as its target namespace; also written "chameleon(N,D)".

override pre-processing

The application, to a schema documentD, of the overrides specified in an<override> elementE, using the rules specified in detail inTransformation forxs:override (§F.2); also written "override(E,D)".

redefine pre-processing

The application, to a schemaS, of the redefinitions specified in an<override> elementE, using the rules specified in detail inIncluding modified component definitions (<redefine>) (§4.2.4); also written "redefine(E,S)".

Note: This specification defines several attributes to allow schema documents and XML instance documents to provide information about the location of relevant schema components. Experience has shown that the similarities and differences among these attributes can be elusive for some readers; a compact overview may be helpful.

Thexsi:schemaLocation andxsi:noNamespaceSchemaLocation attributes may validly appear on elements in an XML instance document. They are technicallyhints: conforming schema-aware processorsmay but need not attempt to dereference the schema documents named in these attributes and include the components described there in the schema used for validation.

TheschemaLocation attribute on the<import> element in a schema document is similarly a hint: a conforming schema-aware processormay but need not attempt to dereference the schema document named by the attribute.

TheschemaLocation attributes on the<include>,<override>, and<redefine> elements in a schema document, on the other hand, are not hints: conforming processorsmust attempt to de-reference the schema document named by the attribute. For non-empty<redefine> elements, it is an error for the attempt to fail; otherwise, the attemptmust be made but it is not an error for it to fail.

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.

4.2.2 Conditional inclusion

Whenever a conforming XSD processor reads a·schema document· in order to include the components defined in it in a schema, it first performs on the schema document the pre-processing described in this section.

Every element in the·schema document· is examined to see whether any of the attributesvc:minVersion,vc:maxVersion,vc:typeAvailable,vc:typeUnavailable,vc:facetAvailable, orvc:facetUnavailable appear among its[attributes].

Where they appear, the attributesvc:minVersion andvc:maxVersion are treated as if declared with typexs:decimal, and their·actual values· are compared to a decimal value representing the version of XSD supported by the processor (here represented as a variableV). For processors conforming to this version of this specification, the value ofV is 1.1.

IfV is less than the value ofvc:minVersion, or ifV is greater than or equal to the value ofvc:maxVersion, then the element on which the attribute appears is to be ignored, along with all its attributes and descendants. The effect is that portions of the schema document marked withvc:minVersion and/orvc:maxVersion are retained ifvc:minVersion ≤V <vc:maxVersion.

Where they appear, the attributesvc:typeAvailable andvc:typeUnavailable are treated as if declared with typelist of xs:QName, and the items in their·actual values· are checked to see whether they name types·automatically known· to the processor. The attributesvc:facetAvailable andvc:facetUnavailable are similarly typed, and checked to see if they name facets supported by the processor.

If an element in a schema document has any of the following:

vc:typeAvailable =T, where any item in the·actual value·T isnot theexpanded name of some type definition·automatically known· to the processor
vc:typeUnavailable =T, where every item in the·actual value·T is theexpanded name of some type definition·automatically known· to and supported by the processor
vc:facetAvailable =F, where any item in the·actual value·F is not theexpanded name of some facet known to and supported by the processor
vc:facetUnavailable =F, where every item in the·actual value·F is theexpanded name of some facet known to and supported by the processor

then the element on which the attribute appears is to be ignored, along with all its attributes and descendants.

Note: It is expected thatvc:typeAvailable etc. will be most useful in testing for·implementation-defined· primitive datatypes and facets, or for derived types for which the processor supplies a definition automatically. The rules just given do not, however, attempt to restrict their use to such tests. If thevc:typeAvailable attribute is used with theexpanded name associated with one of the built-in primitive datatypes, the datatype will (in a conforming processor) always be available, so the test is unlikely to filter out any elements, ever, from the schema document. But such a usage is not in itself an error.

Note: Theexpanded names of the built-in datatypes are as specified in[XML Schema: Datatypes]; theexpanded name of any·implementation-defined· datatype is required by[XML Schema: Datatypes] to be specified by the implementation.

Note: Theexpanded names of the facets (built-in or·implementation-defined·) are theexpanded names of the elements used in XSD schema documents to apply the facets, e.g.xs:pattern for thepattern facet.

Note: It is a consequence of the rules given above that if the·actual value· ofvc:typeAvailable is the empty list (i.e.vc:typeAvailable=""), then the corresponding element isnot ignored. (It does not list any type that is not available.) Conversely, if the·actual value· ofvc:typeUnavailable is the empty list, then the corresponding element is ignored. Similar results hold forvc:facetAvailable andvc:facetUnavailable.

The pre-processing of a schema documentS1 results in a second schema documentS2, identical toS1 except that all elements and attributes inS1 which are to be ignored are absent fromS2. We writeS2 =ci(S1). If the<schema> element information item inS1 is to be ignored, thenS2 is identical toS1 except that any attributes other thantargetNamespace,vc:minVersion orvc:maxVersion are removed from its[attributes], and its[children] is the empty sequence. It isS2, notS1, which is required to conform to this specification.

Note: IfS1 contains no elements or attributes to be ignored, thenS1 andS2 are identical.

Except where conditional-inclusion pre-processing is explicitly mentioned, references to·schema documents· elsewhere in this specification invariably refer to the result of the pre-processing step described here, not to its input, which need not, and in the general case will not, always conform to the rules for schema documents laid out in this specification.

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 elemente and thus violates clause2 of constraintSchema Properties Correct (§3.17.6.1), the pre-processing step described in this section filters out the first element declaration, making it possible for the resulting schema document to be valid and to conform to this specification.

Note that the semantics of thevc:maxVersion attribute is "exclusive". This makes it easier for schema authors to use this feature without leaving gaps in the numeric ranges used to select version numbers.

Example

Suppose that a processor supports an·implementation-defined· primitive namedxpath_expression in namespace "http://example.org/extension_types", and is presented with the following schema document:

<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 fore and omit the second, so that the effective schema document, after pre-processing for conditional inclusion, is:

<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 fore: type in the namespace in question

<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 attributevc:minVersion orvc:maxVersion appears on an element information item in a·schema document·, its·initial value·must be locally·valid· with respect toxs:decimal as perString Valid (§3.16.4).

Whenever any of the attributesvc:typeAvailable,vc:typeUnavailable,vc:facetAvailable, orvc:facetUnavailable, appears on an element information item in a·schema document·, its·initial value·must be locally·valid· with respect to a simple type definition with{variety} =list and{item type definition} =xs:QName, as perString Valid (§3.16.4).

Any attribute from thevc: namespace that appears on an element information item in a·schema document·should be one of the attributes described elsewhere in this document (i.e. one ofvc:minVersion,vc:maxVersion,vc:typeAvailable,vc:typeUnavailable,vc:facetAvailable, orvc:facetUnavailable).

Note: Processors are encouraged to issue warnings aboutvc: attributes other than those named, but it is not an error for such attributes to appear in a·schema document·. The rule just given is formulated with a "should" and not a "must" in order to preserve the ability of future versions of this specification to add new attributes to the schema-versioning namespace.

4.2.3 Assembling a schema for a single target namespace from multiple schema definition documents (`<include>`)

Schema components for a single target namespace can be assembled from several·schema documents·, that is several<schema> element information items:

XML Representation Summary:include Element Information Item

<include
 id =ID
 schemaLocation =anyURI
 {any attributes with non-schema namespace . . .}>
 Content:(annotation?)
</include>

A<schema> information itemmay contain any number of<include> elements. TheirschemaLocation attributes, consisting of a URI reference, identify other·schema documents·, that is<schema> information items.

If two<include> elements specify the same schema location (after resolving relative URI references) then they refer to the same schema document. If they specify different schema locations, then they refer to different schema documents, unless the implementation is able to determine that the two URIs are references to the same resource.

If a·schema document·D₁ contains one or more<include> elements, thenschema(D₁) contains not onlyimmed(D₁) but also all the components ofschema(D₂), for each·schema document·D₂ identified by an<include> element child ofD₁. Such included schema documentsD₂must either (a) have the sametargetNamespace asD₁, or (b) notargetNamespace at all, in which case the components included inschema(D₁) are not those ofschema(D₂) itself, but instead those ofschema(chameleon(tns(D₁),D₂)), that is, the schema corresponding to the result of applying chameleon pre-processing toD₂ to convert it to target namespacetns(D₁).

Schema Representation Constraint: Inclusion Constraints and Semantics

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

1If the·actual value· of theschemaLocation[attribute] successfully resolvesone or more of the following is true:

1.1It resolves to (a fragment of) a resource which is an XML document (of typeapplication/xml ortext/xml with an XML declaration for preference, but this is not required), which in turn corresponds to a<schema> element information item in a well-formed information set.

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

In either case call the<include>d<schema> itemD2 and the<include>ing item's parent<schema> itemD1.

2One of the followingmust be true:

2.1D2 has atargetNamespace[attribute], and its·actual value· is identical to the·actual value· of thetargetNamespace[attribute] ofD1 (whichmust have such an[attribute]).

2.2NeitherD2 norD1 have atargetNamespace[attribute].

2.3D2 has notargetNamespace[attribute] (butD1 does).

2.4D2 does not exist (e.g. because the·actual value· of theschemaLocation[attribute] does not resolve successfully).

3 The appropriatecase among the followingmust be true:

3.1Ifclause2.1 or clause2.2 above is satisfied,thenall of the following are true:

3.1.1D2 corresponds to a conforming schema (call itS2).

3.1.2 The schema corresponding toD1 includes not only definitions or declarations corresponding to the appropriate members of its own[children], but also components identical to all the·schema components· ofS2 (with the possible exception of itsSchema component).

3.2Ifclause2.3 above is satisfied,thenall of the following are true:

3.2.1 LetD2′ be a<schema> information item obtained by performing onD2 the transformationspecified inTransformation for Chameleon Inclusion (§F.1);D2′ corresponds to a conforming schema (call itS2).

Note: The transformation inTransformation for Chameleon Inclusion (§F.1)(a) adds atargetNamespace[attribute] toD2,whose value is the same as that of thetargetNamespace[attribute] ofD1, and (b) updates all unqualifiedQName references so that their namespace names become the·actual value· of thetargetNamespace[attribute].Implementations need not use the[XSLT 2.0]stylesheet given inTransformation for Chameleon Inclusion (§F.1), as long as an equivalent result is produced.In particular, different algorithms for generating a unique namespace prefixmay be used, even if they produce different results.

3.2.2 The schema corresponding toD1 includes not only definitions or declarations corresponding to the appropriate members of its own[children], but also components identical to all the·schema components· ofS2 (with the possible exception of itsSchema component).

Note: The above rule applies recursively. For example, ifA includesB andB includesC, whereA has atargetNamespace[attribute], but neitherB norC does, then the effect is as ifA includedB' andB' includedC', whereB' andC' are identical toB andC respectively, except that they both have atargetNamespace[attribute] the same asA's.

Note: In this case, it isD2′, notD2, which is required by clause3.2.1 to correspond to a conforming schema. In particular, it is not an error forD2 to fail to satisfy all of the constraints governing schema documents, while itis an error ifD2′ fails to satisfy them.

Note: IfD2 imports the target namespace ofD1, then the effect of clause3.2 will be to cause an error owing to the violation of clause1 ofImport Constraints and Semantics (§4.2.6.2) (which forbids a schema document to import its own target namespace). Other constraint violations may also be brought about; caution is advised.

It isnot an error for the·actual value· of theschemaLocation[attribute] to fail to resolve at all,in which case the corresponding inclusionmust not be performed. Itis an error for it to resolve but the rest of clause 1above to fail to be satisfied. Failure to resolve is likelyto cause less than complete·assessment· outcomes, of course.

As discussed inMissing Sub-components (§5.3),·QName·s in XML representations willsometimes fail to·resolve·, rendering components incompleteand unusable because of missing subcomponents. During schemaconstruction, implementationsmust retain·QName· values for such references, in casean appropriately-named component becomes available to discharge thereference by the time it is actually needed.·Absent· target·namespacename·s of such as-yet unresolved reference·QName·s in<include>dcomponentsmust also be converted if clause3.2 issatisfied.

Note: The above is carefully worded so that multiple<include>ing of the same schema document will not constitute a violation of clause2 ofSchema Properties Correct (§3.17.6.1), but applications are allowed, indeed encouraged, to avoid<include>ing the same schema document more than once to forestall the necessity of establishing identity component by component.

If there is a sequence of schema documentsS1,S2, ...Sn, and a sequence of<include> elementsE1,E2, ...En, such that eachS_i contains the correspondingE_i, and eachE_i (wherei <n) points to schema documentS_{i + 1}, andEn points toS1 (i.e. if there is a cycle in the relation defined by the<include> element), then the same schema corresponds to all of the schema documentsS1, ...Sn in the cycle, and it includes the same components as the schema corresponding toS1 in the similar case whereSn has no<include> element pointing atS1.

Note: Informally: cycles of<include> elements are legal, and processors should guard against infinite loops.

4.2.4 Including modified component definitions (`<redefine>`)

Note: The redefinition feature described in the remainder of thissection is·deprecated· and may be removed from future versions ofthis specification. Schema authors are encouraged to avoid itsuse in cases where interoperability or compatibility with laterversions of this specification are important.

In order to provide some support for evolution and versioning, it ispossible to incorporate components corresponding to a schema documentwith modifications. The modifications have a pervasive impact,that is, only the redefined components are used, even when referenced fromother incorporated components, whether redefined themselves or not.

XML Representation Summary:redefine Element Information Item

<redefine
 id =ID
 schemaLocation =anyURI
 {any attributes with non-schema namespace . . .}>
 Content:(annotation | (simpleType |complexType |group |attributeGroup))*
</redefine>

A<schema> information itemmay contain any number of<redefine> elements. TheirschemaLocation attributes, consisting of a URI reference, identify other·schema documents·, that is<schema> information items.

If a schema documentD₁ contains a<redefine> elementE pointing to some schema documentD₂, thenschema(D₁) contains not only the components inimmed(D₁), but also all the components (with the exception, in most cases, of the schema-as-a-whole component) ofredefine(E,schema(D₂)). For any documentD₂ pointed at by a<redefine> element inD₁, itmust be the case either (a) thattns(D₁) =tns(D₂) or else (b) thattns(D₂) is·absent·, in which caseschema(D₁) includes notredefine(E,schema(D₂)) itself butredefine(E,schema(chameleon(tns(D₁),D₂))). That is, the redefinition pre-processing is applied not to the schema corresponding toD₂ but instead to the schema corresponding to the schema documentchameleon(tns(D₁),D₂), which is the result of applying chameleon pre-processing toD₂ to convert it to target namespacetns(D₁).

The definitions within the<redefine> element itself arerestricted to be redefinitions of components from the<redefine>dschema document,in terms of themselves. That is,

Typedefinitionsmust use themselves as their base type definition;
Attributegroup definitions and model group definitionsmust be supersets or subsets of their originaldefinitions, either by including exactly onereference to themselves or by containing only (possibly restricted) componentswhich appear in a corresponding way in their<redefine>d selves.

Not all the components of the<redefine>dschema document need be redefined.

This mechanism is intended to provide a declarative and modular approach toschema modification, with functionality no different except in scope from whatwould be achieved by wholesale text copying and redefinition by editing. Inparticular redefining a type is not guaranteed to be side-effect free: it canhave unexpected impacts on other type definitions which are basedon the redefined one, even to the extent that some such definitions becomeill-formed.

Note: The pervasive impact of redefinition reinforces the need forimplementations to adopt some form of lazy or 'just-in-time' approach tocomponent construction, which is also called for in order to avoidinappropriate dependencies on the order in which definitions and references appear in (collections of) schema documents.

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 tov2.xsd has everything specifiedbyv1.xsd, with thepersonName type redefined, aswell as everything it specifies itself. According tothis schema, elements constrainedby thepersonName typemay end with agenerationelement. This includes not only theauthor element, but also theaddressee element.

Schema Representation Constraint: Redefinition Constraints and Semantics

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

1If there are any element information items among the[children] other than<annotation> then the·actual value· of theschemaLocation[attribute]must successfully resolve.

2If the·actual value· of theschemaLocation[attribute] successfully resolvesone or more of the following is true:

2.1it resolves to (a fragment of) a resource which is an XML document (see clause1.1 ofInclusion Constraints and Semantics (§4.2.3)), which in turn corresponds to a<schema> element information item in a well-formed information set.

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

In either case call the<redefine>d<schema> itemD2 and the<redefine>ing item's parent<schema> itemD1.

3One of the followingmust be true:

3.1D2 has atargetNamespace[attribute], and its·actual value· is identical to the·actual value· of thetargetNamespace[attribute] ofD1 (whichmust have such an[attribute]).

3.2NeitherD2 norD1 have atargetNamespace[attribute].

3.3D2 has notargetNamespace[attribute] (butD1 does).

4 The appropriatecase among the followingmust be true:

4.1Ifclause3.1 or clause3.2 above is satisfied,then

4.1.1D2 corresponds to a conforming schema (call itS2).

4.1.2 The schema corresponding toD1 includes not only definitions or declarations corresponding to the appropriate members of its own[children], but also components identical to all the·schema components· ofS2, with the exception of those explicitly redefined (seeIndividual Component Redefinition (§4.2.4) below and with the possible exception of theSchema component ofS2)).

4.2Ifclause3.3 above is satisfied,then

4.2.1 LetD2′ be a<schema> information item obtained by performing onD2 the transformationspecified inTransformation for Chameleon Inclusion (§F.1);D2′ corresponds to a conforming schema (call itS2).

4.2.2 The schema corresponding toD1 includes not only definitions or declarations corresponding to the appropriate members of its own[children], but also components identical to all the·schema components· ofS2, with the exception of those explicitly redefined (seeIndividual Component Redefinition (§4.2.4) below).

Note: In this case, it isD2′ and notD2, which is required by clause4.2.1 to correspond to a conforming schema. In particular, it is not an error forD2 to fail to satisfy all of the constraints governing schema documents, while itis an error ifD2′ fails to satisfy them.

5Within the[children], each<simpleType>must have a<restriction> among its[children] and each<complexType>must have arestriction orextension among its grand-[children] the·actual value· of whosebase[attribute]must be the same as the·actual value· of its ownname attribute plus target namespace;

6 Within the[children], for each<group> the appropriatecase among the followingmust be true:

6.1Ifit has a<group> among its contents at some level the·actual value· of whoseref[attribute] is the same as the·actual value· of its ownname attribute plus target namespace and that<group> does not have an<element> ancestor,thenall of the following are true:

6.1.1It has exactly one such group.

6.1.2The·actual value· of both that group'sminOccurs andmaxOccurs[attribute] is1 (or·absent·).

6.2Ifit has no such self-reference,thenall of the following are true:

6.2.1The·actual value· of its ownname attributeplus target namespace successfully·resolves· to amodel group definition inS2.

6.2.2 The{model group} of themodel group definition which corresponds to it perXML Representation of Model Group Definition Schema Components (§3.7.2) accepts a subset of the element sequences accepted by that model group definition inS2.

7 Within the[children], for each<attributeGroup> the appropriatecase among the followingmust be true:

7.1Ifit has an<attributeGroup> among its contents the·actual value· of whoseref[attribute] is the same as the·actual value· of its ownname attribute plus target namespace,thenit has exactly one such group.

7.2Ifit has no such self-reference,thenall of the following are true:

7.2.1The·actual value· of its ownname attributeplus target namespace successfully·resolves· to anattribute group definition inS2.

7.2.2The{attribute uses} and{attribute wildcard} of the attribute groupdefinition which corresponds to it perXML Representation of Attribute Group Definition Schema Components (§3.6.2) viewed as the{attribute uses} and{attribute wildcard} of aComplex Type Definition and the{attribute uses} and{attribute wildcard} of that attribute group definition inS2 viewed as the{attribute uses} and{attribute wildcard} of the{base type definition} satisfy clause3 ofDerivation Valid (Restriction, Complex) (§3.4.6.3).

Note: An attribute group restrictively redefined per clause7.2 corresponds to an attribute group whose{attribute uses} consist all and only of those attribute uses corresponding to<attribute>s explicitly present among the[children] of the<redefine>ing<attributeGroup>. No inheritance from the<redefine>d attribute group occurs. Its{attribute wildcard} is similarly based purely on an explicit<anyAttribute>, if present.

Schema Representation Constraint: Individual Component Redefinition

Corresponding to each non-<annotation> member of the[children] of a<redefine> there are one or two schema components inthe<redefine>ing schema:

1The<simpleType> and<complexType>[children] information items eachcorrespond to two components:

1.1One component which corresponds to the top-level definition item withthe samename inthe<redefine>d schema document, as defined inSchema Component Details (§3), except that its{name} is·absent· and its{context} is the redefining component, as defined in clause1.2 below;

1.2One component which corresponds to the information item itself, as definedinSchema Component Details (§3), except that its{base type definition} isthe component defined in clause1.1 above.

This pairing ensures the coherence constraints on type definitionsare respected, while at the same time achieving the desired effect, namely thatreferences to names of redefined components in both the<redefine>ing and<redefine>d schema documents·resolve· to the redefined componentas specified in 1.2 above.

2The<group> and<attributeGroup>[children] each correspond to a single component, as defined inSchema Component Details (§3), except that if and when a self-reference based on aref[attribute] whose·actual value· is the same as the item'sname plus target namespace is·resolved·, a component which corresponds to the top-level definition item of that name and the appropriate kind inS2 is used.

In all cases theremust be a top-level definition item of the appropriate name and kind inthe<redefine>d schema document.

Note: The above is carefully worded so thatmultiple equivalent<redefine>ing of the same schema document will not constitute a violation ofclause2 ofSchema Properties Correct (§3.17.6.1), but applications areallowed, indeed encouraged, to avoid<redefine>ing the sameschema document in the same way more than once to forestall the necessity ofestablishing identity component by component (although this will have to bedone for the individual redefinitions themselves).

4.2.5 Overriding component definitions (`<override>`)

The<redefine> construct defined inIncluding modified component definitions (<redefine>) (§4.2.4) is useful in schema evolution and versioning, when it is desirable to have some guaranteed restriction or extension relation between the old component and the redefined component. But there are occasions when the schema author simply wants to replace old components with new ones without any constraint. Also, existing XSD processors have implemented conflicting and non-interoperable interpretations of<redefine>, and the<redefine> construct is·deprecated·. The<override> construct defined in this section allows such unconstrained replacement.

Note: The name of the<override> element has nothing to do with the use of the term "·override·" to denote the relation between an·instance-specified type definition· and another type. The two mechanisms are distinct and unrelated.

XML Representation Summary:override Element Information Item

<override
 id =ID
 schemaLocation =anyURI
 {any attributes with non-schema namespace . . .}>
 Content:(annotation | (simpleType |complexType |group |attributeGroup |element |attribute |notation))*
</override>

A<schema> information itemmay contain any number of<override> elements. TheirschemaLocation attributes, consisting of a URI reference, identify ("point to") other·schema documents·, that is<schema> information items.

If a schema documentD_new contains an<override> elementE pointing to some schema documentD_old, thenschema(D_new) contains not only the components inimmed(D_new), but also the components inschema(override(E,D_old)). For all such schema documentsD_old, itmust be the case either (a) thattns(D_old) =tns(D_new), or (b) thattns(D_old) is·absent·, in which caseschema(D_new) contains not the components inschema(override(E,D_old)), but those inschema(override(E,chameleon(tns(D_new),D_old))). That is, before the override pre-processsing is applied, chameleon pre-processing is applied toD_old to convert it to target namespacetns(D_new); the override pre-processing is applied to the result, namelychameleon(tns(D_new),D_old).

Note: If the above definition is naively translated into an algorithm, the algorithm may fail to terminate in the case where the graph ofinclude andoverride references among schema documents contains cycles. To guarantee termination, the algorithm must detect when it has reached closure, that is, when further computation will have no effect on the outcome. In particular, it is useful to recognize (a) that it is possible to terminate as soon as conflicting components have been generated (for example, two different type definitions with the same name), and (b) that whenoverride(E,D) (for someE andD) is equivalent toD, no new schema components will be contributed by further processing: this can be detected either by comparing the input and output of the override transformation using a comparator such as the[XPath 2.0]fn:deep-equal function, or by observing the conditions that causeoverride(E,D) to be idempotent, for example the fact thatE is empty.

The children of the<override> elementmay override any source declarations for·named· components which appear among the[children] of the<schema>,<redefine>, or<override> elements in the·target set· of the<override> element information item..

[Definition:] Thetarget set of an<override> element information itemE containsall of the following:

1The schema document identified by theschemaLocation attribute ofE.

2The schema document identified by theschemaLocation attribute of any<override> element information item in a schema document contained in the·target set· ofE.

3The schema document identified by theschemaLocation attribute of any<include> element information item in a schema document contained in the·target set· ofE.

Thetarget set ofE contains no other schema documents.

Note: The·target set· of an<override> element is the transitive closure of the union of the inclusion relation (which contains the pair (S1,S2) if and only ifS1 contains an<include> element pointing toS2) and the override relation (which contains the pair (S1,S2) if and only ifS1 contains an<override> element pointing toS2). It does not include schema documents which are pointed to by<import> or<redefine> elements, unless they are also pointed to by<include> or<override> elements in the relevant schema documents.

Source declarations not present in the target set ofE cannot be overridden, even if they are present in other schema documents consulted in the creation of the schema (e.g. in schema documents pointed to by a<redefine> element). It is not an error for an<override> element to contain a source declaration which matches nothing in the target set, but it will be ignored; in particular, it will not succeed in overriding source declarations in schema documents not part of the target set.

Note: The transformation described inTransformation forxs:override (§F.2) translates both<override> and<include> elements into<override> elements. These<override> elements will, in turn, be handled by transforming their target schema documents. Since every schema document in the target set of the original<override> element is the target of either an<override> element or of an<include> element, it follows that the transformation described inTransformation forxs:override (§F.2) will be applied to every schema document in the target set.

Note: It isnot forbidden for the schema documentD containing an<override> elementE to be in the·target set· ofE.

If applying the override transformation specified inTransformation forxs:override (§F.2) toD andE results in a schema document equivalent toD (e.g. when none of the[children] ofD, or of any<redefine> and<override> elements inD match any of the[children] ofE, except for the[children] ofE themselves), then the effect is the same as for a cyclic set of<include> references, or as for multiple inclusions of the same document (as described in the note at the end ofAssembling a schema for a single target namespace from multiple schema definition documents (<include>) (§4.2.3)).

If applying the override transformation toD andE changes any of the XML representations of components, then the effect ofD being in the·target set· ofE is the same as if two different schema documents containing conflicting definitions for the same components were included. ("As if" is inexact; in this case what happens is, precisely, that two schema documents with conflicting contents are included.)

The definitions within the<override> element itself arenot required to be similar in any way to the source declarations being overridden. Not all the source declarations of the overridden schema document need be overridden.

As this mechanism is very similar to<redefine>, many similar kinds of caution need to be taken in using<override>. Please refer toIncluding modified component definitions (<redefine>) (§4.2.4) for details.

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 tov1.xsd has a complex type namedpersonName with a sequence offirstName andlastName children. The schema corresponding tov2.xsd overridespersonName, by providing a different sequence of element children. All elements with thepersonName type are now constrained to have the sequence ofgivenName andsurname. This includes not only theauthor element, but also theaddressee element.

Schema Representation Constraint: Override Constraints and Semantics

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

1 If the·actual value· of theschemaLocation[attribute] successfully resolvesone or more of the following is true:

1.1 It resolves to (a fragment of) a resource which is an XML document (see clause1.1 ofInclusion 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> itemD_old and the overriding item's parent<schema> itemD_new.

2One of the followingmust be true:

2.1D_old has atargetNamespace[attribute], and its·actual value· is identical to the·actual value· of thetargetNamespace[attribute] ofD_new (whichmust have such an[attribute]).

2.2 NeitherD_old norD_new have atargetNamespace[attribute].

2.3D_old has notargetNamespace[attribute] (butD_new does).

3 The appropriatecase among the followingmust be true:

3.1Ifclause2.1 or clause2.2 above is satisfied,then

3.1.1 LetD_old′ be a<schema> information item obtained by performing onD_old the transformationspecified inTransformation forxs:override (§F.2). ThenD_old′ corresponds to a conforming schema (call itS_old).

3.1.2 The<override> element in schema documentD_new pointing toD_old is replaced by an<include> element pointing toD_old′ and the inclusion is handled as described inAssembling 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 replacementof the<override> element inD_new with an<include> element; any implementation techniquecan be used as long as it produces the required result.

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

Note: Another effect is that if schema documentA containsa source declaration for a componentE, and schema documentBoverridesA with its own declaration forE, and schema documentC in turn overridesB with a third declaration forE, then incalculatingschema(C)

3.1.2.1First, the override ofB byC is handled. The resulting schema document (B′, a modified version ofB) still contains an<override> element referring toA, but the declaration forE contained in it has been replaced by that specified inC.

3.1.2.2Then, the override ofA byB′ (the modified version ofB) is handled.

3.1.2.3The resulting version ofA, containing the declaration forE originally present inC, is included byB′, which is itself included byC.

3.1.2.4The resulting schema contains the version ofE originally specified in schema documentC.

(The references to "first" and "then" here refer to the logical precedenceof operations, not to a required order in which implementationsare required to perform particular tasks.)

3.2Ifclause2.3 above is satisfied,then

3.2.1 LetD_old′ be a<schema> information item obtained by performing onD_old first the transformationspecified inTransformation for Chameleon Inclusion (§F.1) and then thetransformation specified inTransformation forxs:override (§F.2). ThenD_old′ corresponds to a conforming schema (call itS2).

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

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

Note: It isD_old′ and notD_old, which is required to correspond to a conforming schema. In particular, it is not an error forD_old to fail to satisfy all of the constraints governing schema documents, while itis an error ifD_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 clause2 ofSchema 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 inInclusion Constraints and Semantics (§4.2.3) (in particular clause3.1.2 and clause3.2.2); redefinition, as defined inIncluding modified component definitions (<redefine>) (§4.2.4); import, as defined inReferences 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.

4.2.6 References to schema components across namespaces (`<import>`)

As described inXSD Abstract Data Model (§2.2), every top-level schema component is associated witha target namespace (or, explicitly, with none). Furthermore,each schema document carries on its<schema> elementat most onetargetNamespace attribute associating that documentwith a target namespace. This section sets outthe syntax and mechanisms by which referencesmay be made from within a·schema document· to componentsoutside that document's targetnamespace. Also included within the same syntax is an optionalfacility for suggesting the URI of a·schema document· containing definitions and declarations for components from the foreign target namespace.

Note: Some users of version 1.0 of this specification[XSD 1.0 2E] have mistakenlyassumed that theprimary purpose of the<import> is to cause retrieval ofa resource identified by theschemaLocation attribute.Although the function of<import> isunchanged in this version, the presentation below has beenreorganized to clarify the two separate purposes served by<import>, namely(1) to license references, within a schema document, tocomponents in the imported namespace, and (2) to provide informationabout the location of schema documents for imported namespaces.

XML Representation Summary:import Element Information Item

<import
 id =ID
 namespace =anyURI
 schemaLocation =anyURI
 {any attributes with non-schema namespace . . .}>
 Content:(annotation?)
</import>

The<import> element information item identifies namespacesused in external references, i.e. those whose·QName· identifies them as coming from adifferent namespace (or none) than the enclosing schema document'stargetNamespace.

4.2.6.1 Licensing References to Components Across Namespaces

At least two conditions must be satisfied for areference to be made to a foreign component: (1)there must be ameans of addressing such foreign components, and(2) there must be a signal toschema-aware processors that a schema document contains suchreferences. The namespacemechanisms defined by[XML Namespaces 1.1]satisfy the first requirement by allowing foreign componentsto be addressed.(How those components are located is governed by theprocessor's strategies for locating schema componentsin a given namespace, in which theschemaLocation attributeon the<import> element can play a role;see alsoTerminology of schema construction (§C.2).)The<import> element information itemservesto satisfy the second requirement, by identifying namespaces used in external componentreferences, i.e. those whose·QName· identifies them as coming from a namespace different from that of the enclosing schemadocument'stargetNamespace. By contrast, a namespace used for other purposes in a schema document need not be imported.

Note: There is no need, for example, to import the namespace of a vocabulary such as XHTML for use in schema<documentation> elements, unless that same namespace is also used as the target namespace for component references.

If the schema document does refer to components in the XHTMLnamespace, then the schema documentmust include an element of the form

<xs:import namespace="http://www.w3.org/1999/xhtml"/>

(with the possible addition of aschemaLocation attributeand annotations). As just described, this explicit import makes it legitimate to refer to components in the XHTML namespace,as base type definitions, or from within content models.

No import is needed in order to use XHTML to mark up the textappearing within<documentation> elements, sincethat usage does not require the schema being constructed toinclude components from the XHTML namespace. (As a practical matter, this saves the processor the effort tolocate a schema for the XHTML namespace.) Importing ornot importing the XHTML namespace in a schema documenthas no effect on the validity of XHTML within<documentation>elements: elements in the XHTMLnamespace (or any other namespace) are allowed within<appinfo> or<documentation>element in the schema document, because the schema forschema documents inSchema for Schema Documents (Structures) (normative) (§A)declares the type of those elements with a lax wildcard.Also, importing the namespace affects the schema being constructed, not the schema used to validate schemadocuments. The latter is specified inSchema for Schema Documents (Structures) (normative) (§A).

Note: Different designs for namespace import could of course beimagined. In particular, declaring a prefix for a namespace couldautomatically import that namespace.

If each use of a foreign namespace within a schema documentimplicitly imported that namespace into the schema beingconstructed, then using XHTML for documentation would automaticallyresult in the inclusion of XHTML components in the schemadescribed by the schema document. The same logic would alsoapply to any vocabulary used for documentation. Such automatic importwould lead processors to expend unnecessary extra effortto find components for the documentation namespace and would in manycases result in a schema which is not the one intended or desiredby the schema author.

Additionally, the requirement that the<import>element be used explicitly provides a modest level ofredundancy that makes it easier to detect some kinds of errorsin the schema document.

The·actual value· of thenamespace[attribute] indicates that the containing schema documentmay containqualified references to schema components in that namespace (via one or moreprefixes declared with namespace declarations in the normal way). If thatattribute is absent, then the import allows unqualified reference to componentswith no target namespace.

It is a consequence of rules defined elsewherethat if references to components in a given namespaceNappear in a schema documentS,thenSmust contain an<import> elementimportingN.Otherwise, the references will fail to resolve; seeclause4 ofQName resolution (Schema Document) (§3.17.6.2).References in a schema document to foreign namespaces not importedby that schema document (or otherwise accounted for byQName resolution (Schema Document) (§3.17.6.2)) arenot"forward references" in the sense ofThe Mapping between XML Representations and Components (§3.1.3) and arenothandled as if they referred to"missing components" in the sense ofMissing Sub-components (§5.3).

Note that components to be imported need not be in the form of a·schema document· and need not in particular be declared in the particular schema document identified by aschemaLocation attribute; the processoris free to access or construct components using means of its ownchoosing, whether or not aschemaLocation hint is provided.

Example

The same namespace can be used both as the namespaceof elements and attributes appearing in the schema document, and in the course ofdefining schema components in terms of foreign components.The import in this example is necessary because there is a reference to the elementcomponentxhtml:p.if there were no component reference, thenthe import would be unnecessary; no import is needed for use of a namespace in a<documentation> or similar schema document element or attribute name.

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

Sincecomponent references are given as·QNames·,and since the default namespace declaration canonly be used for one of the target namespace and the XSD namespace(which typically differ, exceptin the case of the schema for schema documents),either internal references to the names being defined in a schema documentor the schema declaration and definition elements themselves will normally be explicitly qualified.This example takes the first option — most otherexamples in this specification have taken the second.

4.2.6.2 Providing Hints for Imported Schema Document Locations

The·actual value· of theschemaLocation attribute, if present onan<import> element, gives a hint as to where aserialization of a·schema document· with declarations and definitions for theimported namespace (or none) canpossibly be found. When noschemaLocation[attribute] is present, the schema author is leaving theidentification of that schema to the instance, application or user,via the mechanisms described below inLayer 3: Schema Document Access and Web-interoperability (§4.3). When aschemaLocation attribute is present, itmust contain a single URI reference which the schema author warrants will resolve to aserialization of a·schema document· containing definitions and declarations ofcomponent(s) in the<import>ed namespace.

Conformance profiles may further restrict the use of theschemaLocation attribute. For example, one profile might mandate that the hint be honored by the schema software, perhaps calling for a processor-dependent error should the URI fail to resolve, or mandating that the hint agree with some expected URI value; another profile might mandate that the hint not be honored,etc.

Note: Since both thenamespace andschemaLocation[attribute] are optional, a bare<import/> information itemis allowed. This simply allows unqualified reference to foreigncomponents with no target namespace without giving any hints as to where to find them.

Schema Representation Constraint: Import Constraints and Semantics

In addition to the conditions imposed on<import> elementinformation items by the schema for schema documentsall of the following also apply:

1The appropriatecase among the followingmust be true:

1.1Ifthenamespace[attribute] is present,thenits·actual value· does not match the·actual value· of theenclosing<schema>'stargetNamespace[attribute].

1.2Ifthenamespace[attribute] is not present,thenthe enclosing<schema> has atargetNamespace[attribute]

2If the application schema reference strategy succeeds using the·actual value·s oftheschemaLocation andnamespace[attributes]one of the followingmust be true:

2.1The result is (a fragment of) a resource which is an XML document(see clause1.1 ofInclusion Constraints and Semantics (§4.2.3)), which in turn corresponds to a<schema>element information item in a well-formed information set, which in turncorresponds to a conforming schema.

2.2The result is a<schema>element information item in a well-formed information set, which in turncorresponds to a conforming schema.

In either case call the<schema> itemD2 and the conforming schemaS2.

3 IfD2 exists, that is, clause2.1 or clause2.2above were satisfied, then the appropriatecase among the followingmust be true:

3.1Ifthere is anamespace[attribute],thenits·actual value· is identical to the·actual value· of thetargetNamespace[attribute] ofD2.

3.2Ifthere is nonamespace[attribute],thenD2has notargetNamespace[attribute]

It isnot an error for the application schema component reference strategy to fail. Itis an error for it to succeed butthe rest of clause2 above tofail to be satisfied. Failure is likely to causeless than complete·assessment·outcomes, of course.

The·schema components· (that is{type definitions},{attribute declarations},{element declarations},{attribute group definitions},{model group definitions},{notation declarations}) of a schemacorresponding to a<schema> element information item with one or more<import> element information itemsmust include notonly definitions or declarations corresponding to the appropriatemembers of its[children], but also, for each of those<import> element information items for which clause2 above is satisfied, a set of·schemacomponents· identical to all the·schemacomponents· ofS2 (with the possible exception of theSchema component ofS2).

Note: The above is carefully worded so thatmultiple<import>ing of the same schema document will not constitute aviolation ofclause2 ofSchema Properties Correct (§3.17.6.1), butapplications are allowed, indeed encouraged, to avoid<import>ing thesame schema document more than once to forestall the necessity ofestablishing identity component by component. Given that theschemaLocation[attribute] is only a hint, it is opento applications to ignore all but the first<import> fora given namespace, regardless of the·actual value· ofschemaLocation, but such a strategy risksmissing useful information when newschemaLocations areoffered.

4.3 Layer 3: Schema Document Access and Web-interoperability

4.3.1Standards for representation of schemas and retrieval of schema documents on the Web
4.3.2How schema definitions are located on the Web

Layers 1 and 2 provide a framework for·assessment· and XML definition of schemas in abroad variety of environments. Over time, it is possible that a range of standards andconventions will evolve to supportinteroperability of XSD implementations on the World Wide Web.Layer 3 defines the minimum level of function required of allconformant processors operating on the Web: it is intended that, overtime, future standards (e.g. XML Packages) for interoperability on theWeb and in other environments can be introduced without the need torepublish this specification.

4.3.1 Standards for representation of schemas and retrieval of schema documents on the Web

For interoperability, serialized·schema documents·, like all other Webresources,should be identified by URI andretrieved using the standard mechanisms of the Web (e.g. http, https,etc.) Such documents on the Webmust be part of XML documents (seeclause1.1 ofInclusion Constraints and Semantics (§4.2.3)), and are represented in the standard XMLschema definition form described by layer 2 (that is as<schema> element information items).

Note:there will often be times when a schema document will be acomplete XML document whose document element is<schema>. There will beother occasions in which<schema> items will be contained in otherdocuments, perhaps referenced using fragment and/or[XPointer] notation.

Note: The variations among server software and web site administration policiesmake it difficult to recommend any particular approach to retrieval requestsintended to retrieve serialized·schema documents·. AnAccept header ofapplication/xml,text/xml; q=0.9, */* is perhaps a reasonable starting point.

4.3.2 How schema definitions are located on the Web

As described inLayer 1: Summary of the Schema-validity Assessment Core (§4.1), processors are responsible for providing theschema components (definitions and declarations) needed for·assessment·. Thissection introduces a set of conventions to facilitate interoperabilityfor instance and schema documents retrieved and processed from the Web.

Note: As discussed above inLayer 2: Schema Documents, Namespaces and Composition (§4.2), other non-Webmechanisms for delivering schemas for·assessment· exist, but are outside the scope of thisspecification.

Processors on the Web are free to undertake·assessment· against arbitraryschemas in any of the ways set out inAssessing Schema-Validity (§5.2). However, itis useful to have a common convention for determining the schema to use. Accordingly, general-purpose schema-aware processors (i.e. those notspecialized to one or a fixed set of pre-determined schemas)undertaking·assessment· of an instance document on the webmust behave as follows:

unless directed otherwise by the user,·assessment· is undertaken on the documentelement information item of the instance document;
unless directed otherwise by the user, theprocessor is required to construct a schema corresponding to a schema documentwhosetargetNamespace isidentical to thenamespace name, if any, of the element information item on which·assessment· is undertaken.

The composition of the completeschema for use in·assessment· is discussed inLayer 2: Schema Documents, Namespaces and Composition (§4.2) above.The means used to locate appropriate schema document(s) are processor andapplication dependent, subject to the following requirements:

Schemas are represented on the Web in the form specified above inStandards for representation of schemas and retrieval of schema documents on the Web (§4.3.1);
The author of a document uses namespace declarations toindicate the intended interpretation of names appearing therein;it is possible but not guaranteed thata schema is retrievable viathe namespace name. Accordingly whether a processor's defaultbehavior is or is not to attempt such dereferencing, itmust alwaysprovide for user-directed overriding of that default.
Note: Experience suggests that it is not in all cases safe or desirable froma performance point of view to dereference namespace names as a matter of course. User community and/orconsumer/provider agreements may establish circumstances in which such dereference is a sensibledefault strategy: this specification allows but does not require particular communities toestablish and implement such conventions. Users are always free to supply namespace names as schema location information when dereferencingis desired: see below.
On the other hand, in case a document author (human or not) created adocument with a particular schema in view, and warrants that some orall of the document conforms to that schema, thexsi:schemaLocation andxsi:noNamespaceSchemaLocation[attributes] are provided. The first recordsthe author's warrant with pairs of URI references (one for the namespace name, andone for a hint as to the location of a schema document defining names for thatnamespace name). The second similarly provides a URI reference as a hint as tothe location of a schema document with notargetNamespace[attribute].
Processorsmayattempt to dereference each schema document location URI in the·actual value· of suchxsi:schemaLocation andxsi:noNamespaceSchemaLocation[attributes].Schema processorsshould provide an option tocontrol whether they do so.It isnot an error for suchan attempt to fail, but failure may cause less than complete·assessment· outcomes.
Note: Whether schema location information in the document instance should or should not be dereferenced may vary with the purpose in view.
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 processornot to follow anyschemaLocation hints in the input. Otherwise, the input document could circumvent the agreement and the consumer's validation of the input, by referring to an alternative schema for the same namespaces, which declares the input document schema-valid but which does not adhere to the prior agreement between the data source and the data consumer.
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·post-schema-validation infoset·. In such cases it will often be better to follow theschemaLocation hints.
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 followingschemaLocation hints.
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 attributes on<include>,<redefine>,<override>, and<import> in schema documents, orxsi:schemaLocation andxsi:noNamespaceSchemaLocation attributes in instance documents) are dereferenced and the values are relative references, then the[base URI] of the[owner element]must be used to resolve the relative references.
According to the rules ofLayer 1: Summary of the Schema-validity Assessment Core (§4.1), the corresponding schemamay be lazily assembled, but is otherwise stable throughout·assessment·. Although schema location attributes can occur on any element, and can be processed incrementally as discovered, their effect is essentially global to the·assessment·. Definitions and declarations remain in effect beyond the scope of the element on which the binding is declared.

Example

Multiple schema bindings can be declared using a singleattribute. 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 inschemaLocation can, but need not be identical to those actually qualifying the element within whose start tagit is found or its other attributes. For example, as above, all schema location information can be declared on the document elementof a document, if desired, regardless of where the namespaces are actually used.

Improved or alternative conventions for Web interoperability canbe standardized in the future without reopening this specification. Forexample, the W3C is currently considering initiatives to standardize thepackaging of resources relating to particular documents and/or namespaces: thiswould be an addition to the mechanisms described here for layer 3. Thisarchitecture also facilitates innovation at layer 2: for example, it would bepossible in the future to define an additional standard for the representation ofschema components which allowed e.g. type definitions to be specified piece bypiece, rather than all at once.

5 Schemas and Schema-validity Assessment

The architecture of schema-aware processing allows for a richcharacterization of XML documents: schema validity is not a binarypredicate.

This specification distinguishes between errors in schemaconstruction and structure, on the one hand, and schema validationoutcomes, on the other.

5.1 Errors in Schema Construction and Structure

Before·assessment· can be attempted, a schema is required. Special-purpose applications are free to determine a schema for use in·assessment· by whatever means are appropriate, but general purpose processorsshould implement and document a strategy for assembling a schema, exploiting at least some if not all of the non-hard-coded methods outlined inTerminology of schema construction (§C.2), starting with the namespaces declared in the document whose·assessment· is being undertaken, and the·actual value·s of thexsi:schemaLocation andxsi:noNamespaceSchemaLocation[attributes] thereof, if any, along with any other information about schema identity or schema document location provided by users in application-specific ways, if any.

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 ofSchema Component Details (§3).

If a schema is derived from one or more schema documents (that is, one or more<schema> element information items) based on the correspondence rules set out inSchema Component Details (§3) andSchemas and Namespaces: Access and Composition (§4), two additional conditions hold; both apply to the schema document after the conditional-inclusion pre-processing described inConditional inclusion (§4.2.2) is performed:

It is an error if any such schema document would not befully valid with respect to a schema corresponding to theSchema for Schema Documents (Structures) (normative) (§A), that is, followingschema-validation with such a schema, the<schema> element information items would have a[validation attempted] property with valuefull orpartial and a[validity] property with valuevalid.
It is an error if any such schema document is or containsany element information items which violate any of therelevant Schema Representation Constraints set out inSchema 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 processormust report the fact. However, any further operations performed in the presence of errors are outside the scope of this specification and are not·schema-validity assessment· as that term is defined here.

5.2 Assessing Schema-Validity

With a schema which satisfies the conditions expressed inErrors in Schema Construction and Structure (§5.1) above, the schema-validity of anelement or attributeinformation item (the·validation root·) can be assessed. Fiveprimary approaches to this are describedand given names here; conforming processorsmay but are not requiredto provide interfaces so that they can be invoked in ways consistent with any or all of these approaches.

type-driven validation

The user or application identifies a type definition from among the typedefinitions of the schema. If the·validation root· is an element, then it is validated as describedinSchema-Validity Assessment (Element) (§3.3.4.6)(with the stipulated type definitionas the·governing type definition·); if it is anattribute, then it is validated with respect to that type definitionas described inString Valid (§3.16.4).

Note: Top-level (named) typesshould be supported; support for local types is optional.

element-driven validation

The user or application identifies an element declaration from among the elementdeclarations of the schema and theitem is validated as described inSchema-Validity Assessment (Element) (§3.3.4.6) (withthe stipulated element declaration as the·governing· declaration);

Note: Top-level elementsshould be supported; support for local elements is optional.

attribute-driven validation

The user or application identifies an attribute declaration fromamong the attribute declarations of the schema and the item is validated as described inSchema-Validity Assessment (Attribute) (§3.2.4.3) (withthe stipulated attribute declaration as its·governing·declaration);

lax wildcard validation

The processor starts fromSchema-Validity Assessment (Element) (§3.3.4.6) withno stipulated declaration or definition. If the·validation root· and the schema determine anelement declaration (by the name of the element), an attributedeclaration (by the name of the attribute), or a type definition (byxsi:type), then·strictvalidation· is performed. If they donot identify any declaration or definition, then·lax assessment· isperformed.

Note: The name for this method ofinvocation reflects the fact that it is analogous to the validation ofan element information item which matches alaxwildcard.

strict wildcard validation

The processor starts fromSchema-Validity Assessment (Element) (§3.3.4.6) with nostipulated declaration or definition. If the·validation root·and the schema determine an element declaration (by the name of the element),an attribute declaration (by the name of the attribute), or atype definition (viaxsi:type), then·strict· validation isperformed; if they do not identify any declaration ordefinition, then·lax assessment· is performed.

Note: From the point of view of schema-validity assessment and theresulting·post-schema-validation infoset·, lax and strict wildcard validation produce the same result. The distinction is provided in order to provide two different termsto express the different expectations of the invoking process.

In typical cases strict wildcard validation will beperformed when the invoking process expects the·validation root·to be declared and valid and will otherwise report an error to its environment. If the absence ofa declaration for the·validation root· counts as a successfuloutcome of validation, then it is preferable to uselax wildcard validation instead.

The name for this method of invocationreflects the fact that it is analogous to thevalidation of an element information item which matches astrict wildcard.

Note: For type-, element-, and attribute-driven validation,there is no requirement that the declaration or definitionidentified by the user or application be a top-levelcomponent of the schema. Mechanisms for referring to other components are out of scope for this specification,but see[XML Schema: Component Designators].

[Definition:] The element or attribute information item at which·assessment· begins is called thevalidation root.

The outcome of schema-validityassessment will be manifest in the[validation attempted] and[validity] properties on the·validation root·, and if the·validation root·is an element information item then alsoon its[attributes] and[children], recursively, asdefined byAssessment Outcome (Element) (§3.3.5.1) andAssessment Outcome (Attribute) (§3.2.5.1). There is norequirement that input which is not schema-valid be rejected by anapplication. It is up to applications to decide whatconstitutes a successful outcome ofvalidation.

Note that every element and attribute information itemparticipating in the·assessment· willalso have a[validation context]property which refers back to the·validation root·.

Note: This specification does not reconstruct the XML notion ofroot in either schemas or instances. Equivalentfunctionality is provided for at·assessment·invocation, viaelement-driven validation above.

Note: This specification has nothing normative to say about multiple·assessment· episodes. It shouldhowever be clear from the above that if a processor restarts·assessment· with respect to a·post-schema-validation infoset· some·post-schema-validation infoset·contributions from the previous·assessment· are likelyto be overwritten. Restarting cannonetheless be useful, particularly at a node whose[validation attempted] property isnone, in which case there are three obvious cases in whichadditional useful information couldresult:

·assessment· was not attemptedbecause of a·validation· failure, butdeclarations and/or definitions are available for at least some of the[children] or[attributes];
·assessment· was not attemptedbecause a named definition or declaration was missing, but afterfurther effort the processor has retrieved it.
·assessment· was not attemptedbecause it was·skipped·,but the processor has at least somedeclarations and/or definitions available for at least some of the[children] or[attributes].

5.3 Missing Sub-components

At the beginning ofSchema Component Details (§3), attention is drawn to thefact that most kinds of schema components have properties which are described thereinas having other components, or sets of other components, as values, but thatwhen components are constructed on the basis of their correspondence withelement information items in schema documents, such properties usuallycorrespond toQNames, and the·resolution· of suchQNames can fail, resulting in one or more values of or containing·absent· where a component is mandated.

If at any time during·assessment·, an element or attributeinformation item is being·validated· with respect to a component ofany kind any of whose properties has or contains such an·absent· value, the·validation· is modified,as following:

In the case of attribute information items, the effect is as ifclause1 ofAttribute Locally Valid (§3.2.4.1) hadfailed;
In the case of element information items, the effect is as ifclause1 ofElement Locally Valid (Element) (§3.3.4.3) hadfailed;
In the case of element information items, processorsmust fall back to·lax assessment·.

Because of the value specification for[validation attempted] inAssessment Outcome (Element) (§3.3.5.1), if this situation ever arises, thedocument as a whole cannot show a[validation attempted]offull.

References in aSimple Type Definition tounknown datatypes, or tounknown constraining facets, make the simple type definition unusable in ways similar to having·absent· property values. Often, such references will result in component properties with·absent· values, but not necessarily. In either case they, and likewise any types derived or constructed from them, are handled in the same way as described above for components with·absent· property values.

5.4 Responsibilities of Schema-aware Processors

Schema-aware processors are responsible for processing XML documents,schemas and schema documents, as appropriate given the level of conformance(as defined inConformance (§2.4)) they support,consistently with the conditions set out above.

A Schema for Schema Documents (Structures) (normative)

The XML representation of the schema for schema documents ispresented here as a normative part of the specification, and as anillustrative example of how the XML Schema Definition Language can define itselfusing its own constructs. The names of XSD types,elements, attributes and groups defined here are evocative of theirpurpose, but are occasionally verbose.

There is some annotation in comments, but a fuller annotation willrequire the use of embedded documentation facilities or a hyperlinkedexternal annotation for which tools are not yet readily available.

Like any other XML document, schemadocuments may carry XML and document type declarations. An XMLdeclaration and a document type declaration are provided here forconvenience. Since this schema document describes the XSDlanguage, thetargetNamespace attribute on theschema element refers to the XSD namespaceitself.

Schema documents conforming to this specification may be in XML1.0 or XML 1.1. Conforming implementations may accept input inXML 1.0 or XML 1.1 or both. SeeDependencies on Other Specifications (§1.4).

Independent copies of this material areavailable in an undated (mutable) version athttp://www.w3.org/2009/XMLSchema/XMLSchema.xsdand in a dated (immutable) version athttp://www.w3.org/2012/04/XMLSchema.xsd— the mutable version will be updated with future revisions of this specification, and the immutable one will not.

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 &lt;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 &lt;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">    <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" >    <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   &lt;complexContent>   &lt;restriction base="xs:anyType">   ...   &lt;/restriction>   &lt;/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">    <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">    <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">    <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">    <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">    <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">    <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">          <xs:complexType>            <xs:complexContent>              <xs:restriction base="xs:groupRef">                <xs:sequence>                  <xs:element ref="xs:annotation" minOccurs="0"/>                </xs:sequence>                <xs:attribute name="minOccurs" fixed="1" type="xs:nonNegativeInteger"/>                <xs:attribute name="maxOccurs" fixed="1" type="xs:nonNegativeInteger"/>              </xs:restriction>            </xs:complexContent>          </xs:complexType>        </xs:element>      </xs:choice>    </xs:sequence>  </xs:group>  <xs:complexType name="all">    <xs:annotation>      <xs:documentation>   Only elements allowed inside</xs:documentation>    </xs:annotation>    <xs:complexContent>      <xs:restriction base="xs:explicitGroup">        <xs:group ref="xs:allModel"/>        <xs:attribute name="minOccurs" default="1" use="optional">          <xs:simpleType>            <xs:restriction base="xs:nonNegativeInteger">              <xs:enumeration value="0"/>              <xs:enumeration value="1"/>            </xs:restriction>          </xs:simpleType>        </xs:attribute>        <xs:attribute name="maxOccurs" default="1" use="optional">          <xs:simpleType>            <xs:restriction base="xs:allNNI">              <xs:enumeration value="0"/>              <xs:enumeration value="1"/>            </xs:restriction>          </xs:simpleType>        </xs:attribute>        <xs:anyAttribute namespace="##other" processContents="lax"/>      </xs:restriction>    </xs:complexContent>  </xs:complexType>  <xs:element name="all" type="xs:all">    <xs:annotation>      <xs:documentation source="http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/structures.html#element-all"/>    </xs:annotation>  </xs:element>  <xs:element name="choice" type="xs:explicitGroup">    <xs:annotation>      <xs:documentation           source="http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/structures.html#element-choice"/>    </xs:annotation>  </xs:element>  <xs:element name="sequence" type="xs:explicitGroup">    <xs:annotation>      <xs:documentation           source="http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/structures.html#element-sequence"/>    </xs:annotation>  </xs:element>  <xs:element name="group" type="xs:namedGroup">    <xs:annotation>      <xs:documentation source="http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/structures.html#element-group"/>    </xs:annotation>  </xs:element>  <xs:attributeGroup name="anyAttrGroup">    <xs:attribute name="namespace" type="xs:namespaceList"                  use="optional"/>    <xs:attribute name="notNamespace" use="optional">      <xs:simpleType>        <xs:restriction base="xs:basicNamespaceList">          <xs:minLength value="1"/>        </xs:restriction>      </xs:simpleType>    </xs:attribute>    <xs:attribute name="processContents" default="strict" use="optional">      <xs:simpleType>        <xs:restriction base="xs:NMTOKEN">          <xs:enumeration value="skip"/>          <xs:enumeration value="lax"/>          <xs:enumeration value="strict"/>        </xs:restriction>      </xs:simpleType>    </xs:attribute>  </xs:attributeGroup>  <xs:complexType name="wildcard">    <xs:complexContent>      <xs:extension base="xs:annotated">                 <xs:attributeGroup ref="xs:anyAttrGroup"/>      </xs:extension>    </xs:complexContent>  </xs:complexType>  <xs:element name="any">    <xs:annotation>      <xs:documentation source="http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/structures.html#element-any"/>    </xs:annotation>    <xs:complexType>      <xs:complexContent>        <xs:extension base="xs:wildcard">          <xs:attribute name="notQName" type="xs:qnameList"                        use="optional"/>          <xs:attributeGroup ref="xs:occurs"/>        </xs:extension>      </xs:complexContent>    </xs:complexType>  </xs:element>  <xs:annotation>    <xs:documentation>   simple type for the value of the 'namespace' attr of   'any' and 'anyAttribute'</xs:documentation>  </xs:annotation>  <xs:annotation>    <xs:documentation>   Value is              ##any      - - any non-conflicting WFXML/attribute at all              ##other    - - any non-conflicting WFXML/attribute from                              namespace other than targetNS              ##local    - - any unqualified non-conflicting WFXML/attribute               one or     - - any non-conflicting WFXML/attribute from              more URI        the listed namespaces              references              (space separated)    ##targetNamespace or ##local may appear in the above list, to        refer to the targetNamespace of the enclosing        schema or an absent targetNamespace respectively</xs:documentation>  </xs:annotation>  <xs:simpleType name="namespaceList">    <xs:annotation>      <xs:documentation>   A utility type, not for public use</xs:documentation>    </xs:annotation>        <xs:union memberTypes="xs:specialNamespaceList xs:basicNamespaceList" />  </xs:simpleType>  <xs:simpleType name="basicNamespaceList">    <xs:annotation>      <xs:documentation>   A utility type, not for public use</xs:documentation>    </xs:annotation>    <xs:list>      <xs:simpleType>        <xs:union memberTypes="xs:anyURI">          <xs:simpleType>            <xs:restriction base="xs:token">              <xs:enumeration value="##targetNamespace"/>              <xs:enumeration value="##local"/>            </xs:restriction>          </xs:simpleType>        </xs:union>      </xs:simpleType>    </xs:list>  </xs:simpleType>  <xs:simpleType name="specialNamespaceList">    <xs:annotation>      <xs:documentation>   A utility type, not for public use</xs:documentation>    </xs:annotation>    <xs:restriction base="xs:token">      <xs:enumeration value="##any"/>      <xs:enumeration value="##other"/>    </xs:restriction>  </xs:simpleType>  <xs:simpleType name="qnameList">    <xs:annotation>      <xs:documentation>        A utility type, not for public use      </xs:documentation>    </xs:annotation>    <xs:list>      <xs:simpleType>        <xs:union memberTypes="xs:QName">          <xs:simpleType>            <xs:restriction base="xs:token">              <xs:enumeration value="##defined"/>              <xs:enumeration value="##definedSibling"/>            </xs:restriction>          </xs:simpleType>        </xs:union>      </xs:simpleType>    </xs:list>  </xs:simpleType>  <xs:simpleType name="qnameListA">    <xs:annotation>      <xs:documentation>        A utility type, not for public use      </xs:documentation>    </xs:annotation>    <xs:list>      <xs:simpleType>        <xs:union memberTypes="xs:QName">          <xs:simpleType>            <xs:restriction base="xs:token">              <xs:enumeration value="##defined"/>            </xs:restriction>          </xs:simpleType>        </xs:union>      </xs:simpleType>    </xs:list>  </xs:simpleType>  <xs:simpleType name="xpathDefaultNamespace">    <xs:union memberTypes="xs:anyURI">      <xs:simpleType>        <xs:restriction base="xs:token">          <xs:enumeration value="##defaultNamespace"/>          <xs:enumeration value="##targetNamespace"/>          <xs:enumeration value="##local"/>        </xs:restriction>      </xs:simpleType>    </xs:union>  </xs:simpleType>  <xs:element name="attribute" type="xs:topLevelAttribute">    <xs:annotation>      <xs:documentation           source="http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/structures.html#element-attribute"/>    </xs:annotation>  </xs:element>  <xs:complexType name="attributeGroup" abstract="true">    <xs:complexContent>      <xs:extension base="xs:annotated">                  <xs:group ref="xs:attrDecls"/>                  <xs:attributeGroup ref="xs:defRef"/>      </xs:extension>    </xs:complexContent>  </xs:complexType>  <xs:complexType name="namedAttributeGroup">    <xs:complexContent>      <xs:restriction base="xs:attributeGroup">        <xs:sequence>          <xs:element ref="xs:annotation" minOccurs="0"/>          <xs:group ref="xs:attrDecls"/>                  </xs:sequence>        <xs:attribute name="name" type="xs:NCName" use="required"/>        <xs:attribute name="ref" use="prohibited"/>        <xs:anyAttribute namespace="##other" processContents="lax"/>      </xs:restriction>    </xs:complexContent>  </xs:complexType>  <xs:complexType name="attributeGroupRef">    <xs:complexContent>      <xs:restriction base="xs:attributeGroup">        <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:element name="attributeGroup" type="xs:namedAttributeGroup"             >    <xs:annotation>      <xs:documentation           source="http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/structures.html#element-attributeGroup"/>    </xs:annotation>  </xs:element>  <xs:element name="include">    <xs:annotation>      <xs:documentation           source="http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/structures.html#element-include"/>    </xs:annotation>    <xs:complexType>      <xs:complexContent>        <xs:extension base="xs:annotated">          <xs:attribute name="schemaLocation" type="xs:anyURI" use="required"/>        </xs:extension>      </xs:complexContent>    </xs:complexType>  </xs:element>  <xs:element name="redefine">    <xs:annotation>      <xs:documentation           source="http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/structures.html#element-redefine"/>    </xs:annotation>    <xs:complexType>      <xs:complexContent>        <xs:extension base="xs:openAttrs">          <xs:choice minOccurs="0" maxOccurs="unbounded">            <xs:element ref="xs:annotation"/>            <xs:group ref="xs:redefinable"/>          </xs:choice>          <xs:attribute name="schemaLocation" type="xs:anyURI" use="required"/>          <xs:attribute name="id" type="xs:ID"/>        </xs:extension>      </xs:complexContent>    </xs:complexType>  </xs:element>  <xs:element name="override">    <xs:annotation>      <xs:documentation           source="http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/structures.html#element-override"/>    </xs:annotation>    <xs:complexType>      <xs:complexContent>        <xs:extension base="xs:openAttrs">          <xs:sequence>            <xs:element ref="xs:annotation" minOccurs="0"/>            <xs:group ref="xs:schemaTop" minOccurs="0" maxOccurs="unbounded"/>          </xs:sequence>          <xs:attribute name="schemaLocation" type="xs:anyURI" use="required"/>          <xs:attribute name="id" type="xs:ID"/>        </xs:extension>      </xs:complexContent>    </xs:complexType>  </xs:element>  <xs:element name="import">    <xs:annotation>      <xs:documentation           source="http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/structures.html#element-import"/>    </xs:annotation>    <xs:complexType>      <xs:complexContent>        <xs:extension base="xs:annotated">          <xs:attribute name="namespace" type="xs:anyURI"/>          <xs:attribute name="schemaLocation" type="xs:anyURI"/>        </xs:extension>      </xs:complexContent>    </xs:complexType>  </xs:element>  <xs:element name="selector">    <xs:annotation>      <xs:documentation           source="http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/structures.html#element-selector"/>    </xs:annotation>    <xs:complexType>      <xs:complexContent>        <xs:extension base="xs:annotated">          <xs:attribute name="xpath" use="required">            <xs:simpleType>              <xs:annotation>                <xs:documentation>A subset of XPath expressions for usein selectors</xs:documentation>                <xs:documentation>A utility type, not for publicuse</xs:documentation>              </xs:annotation>              <xs:restriction base="xs:token"/>                            </xs:simpleType>          </xs:attribute>          <xs:attribute name="xpathDefaultNamespace" type="xs:xpathDefaultNamespace"/>        </xs:extension>      </xs:complexContent>    </xs:complexType>  </xs:element>  <xs:element name="field">    <xs:annotation>      <xs:documentation source="http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/structures.html#element-field"/>    </xs:annotation>    <xs:complexType>      <xs:complexContent>        <xs:extension base="xs:annotated">          <xs:attribute name="xpath" use="required">            <xs:simpleType>              <xs:annotation>                <xs:documentation>A subset of XPath expressions for usein fields</xs:documentation>                <xs:documentation>A utility type, not for publicuse</xs:documentation>              </xs:annotation>              <xs:restriction base="xs:token"/>                            </xs:simpleType>          </xs:attribute>          <xs:attribute name="xpathDefaultNamespace" type="xs:xpathDefaultNamespace"/>        </xs:extension>      </xs:complexContent>    </xs:complexType>  </xs:element>  <xs:complexType name="keybase">    <xs:complexContent>      <xs:extension base="xs:annotated">        <xs:sequence minOccurs="0">          <xs:element ref="xs:selector"/>          <xs:element ref="xs:field" minOccurs="1" maxOccurs="unbounded"/>        </xs:sequence>        <xs:attribute name="name" type="xs:NCName"/>        <xs:attribute name="ref" type="xs:QName"/>      </xs:extension>    </xs:complexContent>  </xs:complexType>  <xs:group name="identityConstraint">    <xs:annotation>      <xs:documentation>The three kinds of identity constraints, all with                     type of or derived from 'keybase'.   </xs:documentation>    </xs:annotation>    <xs:choice>      <xs:element ref="xs:unique"/>      <xs:element ref="xs:key"/>      <xs:element ref="xs:keyref"/>    </xs:choice>  </xs:group>  <xs:element name="unique" type="xs:keybase">    <xs:annotation>      <xs:documentation           source="http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/structures.html#element-unique"/>    </xs:annotation>  </xs:element>  <xs:element name="key" type="xs:keybase">    <xs:annotation>      <xs:documentation source="http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/structures.html#element-key"/>    </xs:annotation>  </xs:element>  <xs:element name="keyref">    <xs:annotation>      <xs:documentation           source="http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/structures.html#element-keyref"/>    </xs:annotation>    <xs:complexType>      <xs:complexContent>        <xs:extension base="xs:keybase">          <xs:attribute name="refer" type="xs:QName"/>        </xs:extension>      </xs:complexContent>    </xs:complexType>  </xs:element>  <xs:element name="notation">    <xs:annotation>      <xs:documentation           source="http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/structures.html#element-notation"/>    </xs:annotation>    <xs:complexType>      <xs:complexContent>        <xs:extension base="xs:annotated">          <xs:attribute name="name" type="xs:NCName" use="required"/>          <xs:attribute name="public" type="xs:public"/>          <xs:attribute name="system" type="xs:anyURI"/>        </xs:extension>      </xs:complexContent>    </xs:complexType>  </xs:element>  <xs:simpleType name="public">    <xs:annotation>      <xs:documentation>   A utility type, not for public use</xs:documentation>      <xs:documentation>   A public identifier, per ISO 8879</xs:documentation>    </xs:annotation>    <xs:restriction base="xs:token"/>  </xs:simpleType>  <xs:element name="appinfo">    <xs:annotation>      <xs:documentation           source="http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/structures.html#element-appinfo"/>    </xs:annotation>    <xs:complexType mixed="true">      <xs:sequence minOccurs="0" maxOccurs="unbounded">        <xs:any processContents="lax"/>      </xs:sequence>      <xs:attribute name="source" type="xs:anyURI"/>      <xs:anyAttribute namespace="##other" processContents="lax"/>    </xs:complexType>  </xs:element>  <xs:element name="documentation">    <xs:annotation>      <xs:documentation           source="http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/structures.html#element-documentation"/>    </xs:annotation>    <xs:complexType mixed="true">      <xs:sequence minOccurs="0" maxOccurs="unbounded">        <xs:any processContents="lax"/>      </xs:sequence>      <xs:attribute name="source" type="xs:anyURI"/>      <xs:attribute ref="xml:lang"/>      <xs:anyAttribute namespace="##other" processContents="lax"/>    </xs:complexType>  </xs:element>  <xs:element name="annotation">    <xs:annotation>      <xs:documentation           source="http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/structures.html#element-annotation"/>    </xs:annotation>    <xs:complexType>      <xs:complexContent>        <xs:extension base="xs:openAttrs">          <xs:choice minOccurs="0" maxOccurs="unbounded">            <xs:element ref="xs:appinfo"/>            <xs:element ref="xs:documentation"/>          </xs:choice>          <xs:attribute name="id" type="xs:ID"/>        </xs:extension>      </xs:complexContent>    </xs:complexType>  </xs:element>  <xs:annotation>    <xs:documentation>   notations for use within  schema documents</xs:documentation>  </xs:annotation>  <xs:notation name="XMLSchemaStructures" public="structures"               system="http://www.w3.org/2000/08/XMLSchema.xsd"/>  <xs:notation name="XML" public="REC-xml-19980210"               system="http://www.w3.org/TR/1998/REC-xml-19980210"/>  <xs:complexType name="anyType" mixed="true">    <xs:annotation>      <xs:documentation>   Not the real urType, but as close an approximation as we can   get in the XML representation</xs:documentation>    </xs:annotation>    <xs:sequence>      <xs:any minOccurs="0" maxOccurs="unbounded" processContents="lax"/>    </xs:sequence>    <xs:anyAttribute processContents="lax"/>  </xs:complexType>  <xs:annotation>    <xs:documentation>      In keeping with the XML Schema WG's standard versioning policy,       the material in this schema document will persist at the URI      http://www.w3.org/2012/04/XMLSchema.xsd.      At the date of issue it can also be found at the URI      http://www.w3.org/2009/XMLSchema/XMLSchema.xsd.      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.xsd will change accordingly;       the version at http://www.w3.org/2012/04/XMLSchema.xsd will not change.      Previous dated (and unchanging) versions of this schema document       include:       http://www.w3.org/2012/01/XMLSchema.xsd          (XSD 1.1 Proposed Recommendation)        http://www.w3.org/2011/07/XMLSchema.xsd          (XSD 1.1 Candidate Recommendation)        http://www.w3.org/2009/04/XMLSchema.xsd          (XSD 1.1 Candidate Recommendation)        http://www.w3.org/2004/10/XMLSchema.xsd          (XSD 1.0 Recommendation, Second Edition)        http://www.w3.org/2001/05/XMLSchema.xsd          (XSD 1.0 Recommendation, First Edition)    </xs:documentation>  </xs:annotation></xs:schema>

B Outcome Tabulations (normative)

To facilitate consistent reporting of schema errors and·validation·failures, this section tabulates and provides unique names for all theconstraints listed in this document. Wherever such constraints have numberedparts, reportsshould use the name given below plus the part number, separatedby a period ('.'). Thus for examplecos-ct-extends.1.2should beused to report a violation of the clause1.2 ofDerivation Valid (Extension) (§3.4.6.2).

C Terminology for implementation-defined features (normative)

This section defines some terms for use in describingchoices made by implementations in areas where the effect of XSD features is explicitly·implementation-defined·.

Future versions of this specification are expected to usethe terminology defined here to specify conformance profiles.Conformance profiles may also be defined by other specificationswithout requiring any revision to this specification.

C.1 Subset of the Post-schema-validation Infoset

This specification defines a number of ways in which theinformation set taken as input is augmented in the courseof schema-validity assessment. Conforming processorsmayprovide access to some or all of this information; in theinterests of simplifying discussion and documentation, thissection defines names for several subsets of the PSVI, withthe intention of simplifying short-hand descriptions ofprocessors. These termsmay be used to describe what parts ofthe PSVI a particular schema processor provides access to, orto specify requirements for processors, or for other purposes.A processor provides access to a particular subsetof the PSVI if and only if it makes accessible some representationof the information in question, for information items to whichit is applicable. (The properties labeled "if applicable"or "where applicable" below are simply the most obviouscases of properties which do not apply to every information item;the same qualification implicitly applies to all properties listedbelow.)

If other subsets of the PSVI prove important in practice it isexpected that definitions of those subsetsmay be provided byother specifications or in later revisions of this one.

The definition in this section of a term denoting a particularsubset of the PSVI does not constitute a requirement thatconforming processors provide access to that subset.

root-validity subset

[Definition:] Theroot-validity subset of the PSVI consists of the following properties of the·validation root·:

instance-validity subset

[Definition:] Theinstance-validity subset of the PSVI consists ofthe·root-validity subset·, plus the following properties on elements,wherever applicable:

and the following properties on attributes, wherever applicable:

type-aware subset

[Definition:] Thetype-aware subset of the PSVI consists of the·instance-validity subset·, plus the following items and properties.It is intended that the type-aware subset of the PSVI includeall the information needed by schema-aware XQuery 1.0 orXSLT 2.0 processors.In each case, the information is to be provided in some·implementation-defined· representation. For elements:

[element attribution]
[element declaration]
[nil]
[type definition]
[member type definition] (where applicable)
[schema normalized value] (where applicable)
[schema actual value] (where applicable)

and for attributes:

[attribute attribution]
[attribute declaration]
[type definition]
[member type definition] (where applicable)
[schema normalized value] (where applicable)
[schema actual value] (where applicable)

Note: In a future draft of this specification, it is expected thata list of specific component properties to which accessshould ormust be provided will be included. No suchlist is present in the current draft; input from readers,users, schema authors, and implementors as to what propertiesare most usefully exposed in this subset would be very welcome.

lightweight type-aware subset

[Definition:] Thelightweight type-aware subset of the PSVI providesthe same information as the·type-aware subset·, except that instead of providingdirect access to schema components, it provides only their names andrelated information.For elements:

[match information]
[type definition name]
[type definition namespace]
[type definition type]
[type definition anonymous]
[member type definition name] (where applicable)
[member type definition namespace] (where applicable)
[member type definition anonymous] (where applicable)

and for attributes:

[match information]
[type definition name]
[type definition namespace]
[type definition type]
[type definition anonymous]
[member type definition name] (where applicable)
[member type definition namespace] (where applicable)
[member type definition anonymous] (where applicable)

full instance subset

[Definition:] Thefull instance subset of the PSVI includes almost allproperties defined by this specification as applying toelement and attribute information items, but excludes schema components. Itconsists ofthe·instance-validity subset·, plus the following properties for elements:

[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] (where applicable)
[member type definition namespace] (where applicable)
[member type definition anonymous] (where applicable)
[schema normalized value] (where applicable)
[schema actual value] (where applicable)
[schema default] (where applicable)
[schema information] some·implementation-defined·representation (including at least thenames of resources from which components were drawn)

and the following for attributes:

[match information]
[type definition name]
[type definition namespace]
[type definition type]
[type definition anonymous]
[member type definition name] (where applicable)
[member type definition namespace] (where applicable)
[member type definition anonymous] (where applicable)
[schema normalized value]
[schema actual value] (where applicable)
[schema default] (where applicable)
[schema specified] (where applicable)

full PSVI with components

Thefull PSVI with components consists ofevery property and information item defined in thisspecification.

In exposing element declarations, attribute declarations,type definitions, and other components, processorsproviding access to the full subset must provide somerepresentation for all of the defined properties of thecomponents. Note that although the properties are oftenredundant with other information, it is not required thatthe full subset include more than one representation ofredundant information.

Note: The PSVI is a description of an information set,not a specification of a data structure or an application-programminginterface. For convenience, this specification definesin some cases more than one term for denoting a particularpiece of information: for example, the[type definition name] property of an element and the[name]property of the[type definition] property of that element are the same piece of information.If the[type definition] is supplied, then the[typedefinition name] is necessarily also available.

Similar observations can be made for other properties present inthe full-instance subset but not mentioned here. Processorsshould allow access to the information without requiringusers or applications to distinguish between the differentnames or access paths under which it might be described in thisspecification.

C.2 Terminology of schema construction

        C.2.1Identifying locations where components are sought
        C.2.2Identifying methods of indirection
        C.2.3Identifying the key for use in indirection
        C.2.4Identifying when to stop searching
        C.2.5Identifying how to react to failure

Conforming processorsmay implement any combination of thefollowing strategies for locating schema components, in anyorder. Theymay also implement other strategies.

The terminology offered here is intended to be useful indiscussions of processor behavior, whether documentingexisting behavior or describing required behavior.

General-purpose processorsshould support multiplemethods for locating schema documents, and provide usercontrol over which methods are used and how to fall back incase of failure.

C.2.1 Identifying locations where components are sought

Some terms describe how a processor identifies locations fromwhich 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.·General-purpose· processors are additionally required to be able to·validate· documents against the XSD schema for schema documents.)

·automatically known· components

Full knowledge of one or more components isbuilt into the processor; these componentsmay be made available automatically by being includedby that processor in every schema it constructs,or theymay be included only under certain·implementation-defined· conditions (e.g. an explicitimport of the relevant namespace, or choice ofa specified invocation option).

Note: All processors arerequired to have some built-in knowledge of of the built-in components.

hard-coded schema locations

A list of locations at whichschema documents will be sought is built into the processor.Particular locations can be associated with specificnamespaces or can be used to seek any schema document.

named pairs

At invocation time, the user passes a set orsequence of (namespace-name, schema document) pairs to theprocessor, e.g. as a command-line option. (Can be used withearly or slow exit strategy.) The namespace name is usedas 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 schemadocuments, or identifiers for schema documents (e.g. URIs), to theprocessor, e.g. as a command-line option. Each schema documentis associated with its target namespace, if any.(Can be used with early orslow exit strategy.)

interactive inquiry

For each namespace, the processor asksthe user interactively (though mechanisms not specifiedhere) where to seek the required schema components.

Note: This will perhaps be most useful as a fallback after other methodshave failed.

namespace name

For each namespace, the processor attemptsto dereference the namespace name; if a schema document isreturned, it is processed. If some other kind of resource representation isreturned, processorsmay interpret its content to locate a schema document.

Note: For example, if a RDDL document is returned,a processormay search the RDDL document forrddl:resourceelements with the well-known propertyxlink:role= "http://www.w3.org/2001/XMLSchema"and then attempt to dereference the location(s) indicated on thexlink:href attribute of the link.

schemaLocation hints in XML instance document

For each namespace, if the inputdocument includes one or more schemaLocation hints for thatnamespace, the processor attempts to dereference thoselocations.

schemaLocation hints in schema documents

For each namespace, if a schema document being processedincludes one or more schemaLocation hints for thatnamespace (e.g. on animport element, the processor attempts to dereference thoselocations.

local repository

For each namespace, a local repository ofschema components is consulted. In some situations the consultation will require a key, in which see the terminology for indirectiongiven below.

C.2.2 Identifying methods of indirection

Some terms describe various methods of indirection throughlocal catalogs, search paths, or local repositories of schemadocuments and/or schema components. In each of these, a‘search key’ is assumed which helps to control theindirection. Terms for different sorts of search key aredefined below.

path indirection

The processor has (hard-coded or acceptedas a parameter at invocation time or acquired from theenvironment) a series of expressions into which a search keyis substituted. After substitution, each element of theseries is interpreted as a file-system path and a schemadocument is sought at the location indicated by that path.

URI indirection

The processor has (hard-coded or acceptedas a parameter at invocation time or acquired from theenvironment) a series of expressions into which a search keyis substituted. After substitution, each element of theseries is interpreted as a URI and a schema document issought 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 atinvocation time or acquired from the environment) using asearch 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 schemacomponents is consulted using a search key.

recursion

The location(s) returned by a catalog or otherindirection mechanism are not consulted immediately butinstead used as a key in a renewed indirection. Only afterthe indirection mechanism fails to return a value is anattempt made to dereference the last location returned.

non-recursion

The location(s) returned by a catalog orother indirection mechanism are consulted immediately; theyare not used in recursive indirections.

C.2.3 Identifying the key for use in indirection

Locating schema components by means of any of the ‘indirect’methods just identified will sometimes involve the specification of avalue of some kind as a search key. Processorsmay vary intheir choice of values to use as the key:

namespace key

The namespace name is used as a key.

location key

A location (e.g. a schema location hint or thelocation specified in a catalog or by the user) is used as akey.

C.2.4 Identifying when to stop searching

When more than one location is available for a givennamespace, two distinct behaviors can be distinguished; theseare orthogonal to other terms defined here:

early-exit

When more than one location is available for agiven namespace, the processor attempts each in turn. Whena location is successfully dereferenced and a schemadocument is obtained, the later locations on the list areignored.

slow-exit

When more than one location is available for agiven namespace, the processor attempts each in turn. Alllocations are tried, even if a schema document for thenamespace has been obtained.

C.2.5 Identifying how to react to failure

When a processor seeks schema components at a particularlocation, but fails to find components of the namespacein question at that location, several differentways of responding to that failure can be distinguished:

error

The processor signals an error in some manner appropriateto its construction and environment. Some processorsand some users will find it useful to distinguish fatal errors (whichcause processing to halt) from recoverable errors.

continue

The processor signals no fatal error and continues its searchfor components in the namespace in question by attemptinganother location.

C.3 Other Implementation-defined Features

This section defines terms intended to be useful in describing other implementation-defined choices.

XML-1.0-based datatypes

The datatypes defined by[XML Schema: Datatypes], taking the relevant definitions from[XML 1.0] and[Namespaces in XML 1.0],for datatypes which depend on definitions from those specifications.

XML-1.1-based datatypes

The datatypes defined by[XML Schema: Datatypes], taking the relevant definitions from version 1.1 of[XML 1.1] and[XML Namespaces 1.1],for datatypes which depend on definitions from those specifications.

D Required Information Set Items and Properties (normative)

This specification requires as a precondition for·assessment· an information set as defined in[XML Infoset] which contains at least the following information items and properties:

Attribute Information Item

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, infosetsshould support the[unparsed entities] property of the Document Information Item. Failure to do so will mean all items of typeENTITY orENTITIES will fail to·validate·. If the[unparsed entities] property is supported, the following is also required:

Unparsed Entity Information Item

[name],[system identifier],[public identifier]

This specification does not require any destructive alterations to the inputinformation set: all the information set contributions specified herein are additive.

This appendix is intended to satisfy the requirements forConformance to the[XML Infoset] specification.

E Checklists of implementation-defined and implementation-dependent features (normative)

E.1 Checklist of implementation-defined features

[Definition:] Animplementation-defined feature or behaviormay vary among processors conforming to this specification; the precise behavior is not specified by this specification butmust be specified by the implementor for each particular conforming implementation. (In the latter respect,·implementation-defined· features differ from·implementation-dependent· features.)

This appendix provides a summary of XSDfeatures whose effect is explicitly·implementation-defined·. Any software which claims to conform to this specificationmust describe how these choices have been exercised, indocumentation which accompanies any conformance claim.

In describing the choices made for a given processor, it is hoped that the terminology defined inTerminology for implementation-defined features (normative) (§C)will be found useful.

1XSD 1.1 depends on otherspecifications for the definitions of some data typessuch asstring,QName,NCName, and for the definition of whitespace. As noted inDependencies on Other Specifications (§1.4), it is·implementation-defined· whether a schema processor takes the definition ofstring from[XML 1.1] or from[XML 1.0].With regard to the other types which depend on other specifications(e.g.NCName and related types),all current editions of[XML 1.0],[XML 1.1],[Namespaces in XML 1.0], and[XML Namespaces 1.1]have identical definitions of these constructs. Future editions, however, couldintroduce changes. Implementationsmay support either the definitions in thecurrent specifications, or definitions in future specifications that supersedethem, or both. It is·implementation-defined· which.

2It is·implementation-defined· whether a schema processorcan read schema documents in the form of XML documents.(SeeConformance (§2.4).)

3Whether a processor is able to retrieve schema documents from the Webis·implementation-defined·. (SeeConformance (§2.4),which defines "·Web-aware·" processorsas processors which can retrieve schema documents from the Web.)

4The way in which a processor is invoked, and the way inwhich values are specified for the schema to be used,the information item to be validated,and the declaration or definition with which to beginvalidation, is·implementation-defined·. (SeeAssessing Schema-Validity (§5.2).)

5The 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·implementation-defined·.(SeeConformance (§2.4).)

6It is·implementation-defined· which information items and properties in the PSVI the processor provides access to, if any.(SeeSubset of the Post-schema-validation Infoset (§C.1) for some subsets of the PSVI forwhich this specification provides names and definitions.)

7When the·post-schema-validation infoset· includes[type definition name] andsimilar properties, it is·implementation-defined· whetherunique names are provided for anonymous type definitions.

8The method used for assembling a set of schema componentsfor use in validation is·implementation-defined·.(SeeHow schema definitions are located on the Web (§4.3.2) for the normative prose andTerminology of schema construction (§C.2) for some terminology whichcan be used in describing implementation choices.)

9It is·implementation-defined· whether a schema processorprovides a value for the[type definition name]and[member type definition name]properties of attribute and element information-items(seeAttribute Validated by Type (§3.2.5.4) andElement Validated by Type (§3.3.5.4)). If it does so, the choice of name is·implementation-dependent·.

10Everything·implementation-defined· in[XML Schema: Datatypes] is also·implementation-defined· in this specification.

Note: This includes, but is not limited to, the choiceof·XML-1.0-based·or·XML-1.1-based·datatypes, or both;support for·implementation-defined· primitive datatypes; support for·implementation-defined· ordinary datatypes;whether·implementation-defined· datatypes are automaticallydeclared or not;whether·implementation-defined· datatypes are automaticallyincluded in every schema or not;support for·implementation-defined· constraining facets;and the order in which·implementation-defined· pre-lexicalfacets are applied to literals.See theappendix onimplementation-defined and implementation-dependentfeatures in[XML Schema: Datatypes].

11It is·implementation-defined· whether a processor detects violations of clause2.4.2 ofDerivation Valid (Restriction, Complex) (§3.4.6.3) (a) always by examination of the schema in isolation, (b) only when some element information item in the input document is valid against its·governing type definition·T but not againstT.{base type definition}, or (c) sometimes the one and sometimes the other. In case (c), the circumstances in which the processor does one or the other are·implementation-dependent·.

12It is·implementation-defined· when a processor detects type errors in XPath expressions and whether it treats type errors as static or dynamic errors.

The values of current dateTime and implicit timezone are also·implementation-defined· in the evaluation of XPath expressions, as described inXPath Evaluation (§3.13.4.2).

The values of various properties in the static context used for XPath evaluation are·implementation-defined·, as described inXPath Valid (§3.13.6.2).

13 It is·implementation-defined· under what conditions a processor will detect the equivalence of two distinctType Table orType Alternative components. All processorsmust detect equivalence under certain specified conditions, but the ability to detect equivalence under other conditions is not constrained. SeeElement Declarations Consistent (§3.8.6.3).

14 It is·implementation-defined· what effect invalid elements within<annotation> have on the construction of schema components from a schema document, and whether a processor treats schema documents which are invalid only in consequence of containing such invalid elements as being in·error· or not.

15It is·implementation-defined· whether an implementation provides user options to retain comments and processing instructions in the[XDM] data model instance used for checking assertions, as described inAssertion Satisfied (§3.13.4.1).

16The function signatures available when XPath expressions in type alternatives are evaluated is·implementation-defined·, as described inConstraints on Type Alternative Schema Components (§3.12.6).

E.2 Checklist of implementation-dependent features

[Definition:] Animplementation-dependent feature or behaviormay vary among processors conforming to this specification; the precise behavior is not specified by this or any other W3C specification and is not required to be specified by the implementor for any particular implementation. (In the latter respect,·implementation-dependent· features differ from·implementation-defined· features.)

This appendix provides a summary of XSD features whose effect is explicitly·implementation-dependent·. Choices made by processors in these areas arenot required to be documented.

When a default value of typeQName orNOTATION is applied to an element or attribute information item, it is·implementation-dependent· whether·namespace fixup· occurs to ensure that the{lexical form} maps to the{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], it is·implementation-dependent· which prefix is used for the attribute.
When a default value is supplied for a defaulted attribute and·namespace fixup· is performed, it is·implementation-dependent· what prefix is used in the new namespace information item.
When a default value is supplied for a defaulted attribute and·namespace fixup· is performed, it is·implementation-dependent· whether the consistency of the information set is preserved by (a) adding the new binding to the descendants of the element on which the defaulted attribute occurred, or by (b) undeclaring the new binding on the children of that element. When[Namespaces in XML 1.0] rather than[XML Namespaces 1.1] is in use, namespace bindings cannot be undeclared, so the behavior is·implementation-dependent· only for those implementations which do support[XML Namespaces 1.1].
If more than oneIdentity-Constraint Definition fails to be satisfied, it is·implementation-dependent· which of them are included in the[failed identity constraints] property of PSVI.
If more than oneAssertion fails to be satisfied, it is·implementation-dependent· which of them are included in the[failed assertions] property of PSVI.
The order ofAnnotation components within various components' {annotations} property is·implementation-dependent·.
If a name is supplied for anonymous components (for example,[type definition name] and[member type definition name] properties in the·post-schema-validation infoset·), the choice of name is·implementation-dependent·.
If a processor detects some violations of clause2.4.2 ofDerivation Valid (Restriction, Complex) (§3.4.6.3) by examination of the schema in isolation, and others only when some element information item in the input document is valid against its·governing type definition·T but not againstT.{base type definition}, then the circumstances in which the processor does one or the other are·implementation-dependent·.

F Stylesheets for Composing Schema Documents (Normative)

The transformations specified in the following sections in the form of[XSLT 2.0] stylesheets are used when assembling schemas from multiple schema documents. Implementations do not have to perform[XSLT 2.0] transformation, or use the stylesheets given here, as long as the same result is produced.

F.1 Transformation for Chameleon Inclusion

When a<schema> information itemD2 without atargetNamespace[attribute] is included (Assembling a schema for a single target namespace from multiple schema definition documents (<include>) (§4.2.3)), redefined (Including modified component definitions (<redefine>) (§4.2.4)), or overridden (Overriding component definitions (<override>) (§4.2.5)) by another<schema>D1 with atargetNamespace[attribute], the following transformation, specified here as an[XSLT 2.0] stylesheet, is applied toD2 before its contents are mapped to schema components. The transformation performs two tasks:

Add atargetNamespace[attribute] toD2, whose valueis the same as that of thetargetNamespace[attribute] ofD1.
Update all QName references inD2 that do not have a namespace nameso that their namespace names become the·actual value· of thetargetNamespace[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>

F.2 Transformation for`xs:override`

When a<schema> information itemD1 contains<override> elements, the transformation specified in the following[XSLT 2.0] stylesheet is performed once for each such<override> element. It requires as parameters (a) the<override> element inD1 (call itO1) as theoverrideElement parameter and (b) the<schema> element of the schema documentD2 identified by theschemaLocation attribute ofO1 as theoverriddenSchema parameter. The transformation produces another<schema> elementD2′, which is equivalent toD2 except that some elements inD2 are replaced or modified.

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] ofD2′ (for example,targetNamespace anddefaultAttributes) are copies of the[attributes] ofD2.

For each element information itemE2 in the[children] of any<schema> or<redefine> element information item withinD2, the appropriatecase among the following is true:

1IfE2 has element type<simpleType>,<complexType>,<group>,<attributeGroup>,<element>,<attribute>, or<notation>, andO1 has a childE1 with the same element type and the same value for itsnameattribute,thenD2′ has a copy ofE1 in the location corresponding toE2's place inD2.

2IfE2 has one of the element types specified in clause1, butO1 has no matching child,thenD2′ has a copy ofE2 in the place corresponding to the location ofE2 inD2.

3IfE2 has element type<include>,thenD2′ has an<override> elementwithschemaLocation =E2.schemaLocationand[children] which are copies of those ofO1.

4IfE2 has element type<override>,thenD2′ has an<override> elementE2′, withE2′.schemaLocation =E2.schemaLocationand[children] which are drawn from among the[children] ofE2 andO1, as specified bythe appropriatecase among the following:

4.1Ifa child ofE2 and a child ofO1 match as described in clause1,thenE2′ has a child which is a copy of the child ofO1.

4.2Ifa child ofE2 matches no child ofO1 as described in clause1,then(as described in clause2)E2′ has a child which is a copy of the child ofE2.

4.3Ifa child ofO1 matches no child ofE2 as described in clause1,thenE2′ has a child which is a copy of the child ofO1.

Note: Informally, the rule just given has the effect thatE2′ contains copies of (a) all the[children] ofO1, as well as of (b) all of the[children] ofE2 which are not overridden by some child ofO1. The copies corresponding to[children] ofE2 come first, followed by the copies of those[children] ofO1 which matched nothing inE2.

5IfE2 has any other element type,thenD2′ has a copy ofE2 in the placewhich corresponds to the location ofE2 inD2.

The base URI ofD2′ is the same as that ofD2.

Note: Informally,D2′ is likeD2 except that (a) any elements matched by any[children] ofO1 are overridden (replaced) by the corresponding[children] ofO1, (b) any schema documents included by means of<include> elements inD2 are overridden (transformed) byO1 instead of being included without change, and (c) any schema documents overridden by means of<override> elements inD2 are to be overridden (transformed) both as specified in the<override> elements inD2 and as specified inO1; if both apply, the information inO1 takes precedence.

The result is that the transformation described byO1 is applied to all the document in the·target set· ofO1.

Note: BecauseD2 andD2′ have the same base URI, relative references inD2′ will be unaffected by the transformation.

Stylesheet forxs: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 Changes since version 1.0 (non-normative)

G.1 Changes made since version 1.0

        G.1.1Relationship between XSD and other specifications
        G.1.2XSD versions
        G.1.3Changes to content models
        G.1.4Assertions and XPath
        G.1.5Derivation of complex types
        G.1.6Changes to complex type definitions
        G.1.7ID, IDREF, and related types
        G.1.8Simple type definitions
        G.1.9Element declarations
        G.1.10Attribute declarations
        G.1.11Component structure
        G.1.12The process of validation
        G.1.13The post-schema-validation infoset
        G.1.14Conformance
        G.1.15Schema composition
        G.1.16Other substantive changes
        G.1.17Clarifications and editorial changes

Note: The grouping of changes below is intended to make the list easier to scan. It is an ad hoc grouping for convenience to which no great significance should be attached. Some changes could have been listed in more than one place; in such cases the choice was arbitrary.

G.1.1 Relationship between XSD and other specifications

Changes to the relationship between this and other specifications:

Support for XML 1.1 has been added.It is now implementation defined whether datatypes dependenton definitions in XML ([XML 1.1],[XML 1.0]) and Namespaces in XML ([XML Namespaces 1.1],[Namespaces in XML 1.0]) use the definitions asfound in version 1.1 or version 1.0 of those specifications.
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 insteadmay support later editions, thus allowing users of this specification to benefit from corrections to other specifications on which this one depends.
The XPath subset for selectors and fields in sectionSelector Value OK (§3.11.6.2) andFields Value OK (§3.11.6.3) has been revised to align its tokenization rules better with[XPath 2.0]; this resolves issue8454 Tokens in XPath subset for selectors/fields.

G.1.2 XSD versions

Schema language versions:

A conditional inclusion mechanism is defined, roughly analogous to the XSLT 2.0use-when attribute or to the C preprocessor#ifdef construct. By means of thevc:minVersion andvc:maxVersion attributes, a simple forward-processing mechanism is supplied, so that conforming XSD 1.1 processors can successfully ignore constructs introduced in future versions (if any) of XSD, and so that schema authors can define schemas which use newer constructs when available but can fall back on older constructs when the newer constructs are not available.
Identifiers for different versions of XSD are now defined in sectionSchema Language Identifiers (§1.3.4).

G.1.3 Changes to content models

Content models:

TheUnique Particle Attribution (§3.8.6.4)constraint has been relaxed. While competition between two·element particles· is still forbidden, as is competition betweentwo·wildcard particles·, competition between an·element particle· anda·wildcard particle· is no longer forbidden. In the course ofmaking this substantive change, some editorial changes havealso been made, in order to make the exposition clearer.(Readers familiar with version 1.0 of this specification willfind that the constraint works in almost exactly the same wayas it did in 1.0, except that content models in which an inputitem matches either a·wildcard particle· or an·element particle· arenow allowed.)
Content models may now use the<openContent> element to specify contentmodels with "open content". Such contentmodels allow elements not explicitly mentioned inthe content model to appear in the document instance; it isas if wildcards were automatically inserted at appropriatepoints within the content model. By specifying what kind ofwildcard is implicitly inserted, the schema author canadjust the degree of openness and determine what elementsare accepted by the open content; the schema author can alsospecify that the content model should be open everywhere, oronly at the end. A schema-document wide default may beset, which causes all content models to be open unlessotherwise specified.
Wildcards may now be defined which allow names in anynamespace but those in a set of proscribed namespaces.(In version 1.0 of this specification, only a singlenamespace, the target namespace of a schema document,could be proscribed.) Also, wildcards can now be writtenwhich match any element in a set of namespaces butwhich exclude a particular set of qualified names frommatching the wildcard.Finally, the keyword##definedSibling can be used to exclude all elements explicitly mentioned in a content model (and all elements substitutable for those elements).
Wildcards can now be defined which match any element(in the specified namespaces) which doesnotmatch an element declaration in the schema (so-called"not-in-schema" wildcards).
Several of the constraints imposed by version 1.0 of this specification onall-groups have been relaxed:
1. Wildcards are now allowed inall groups.
2. The value ofmaxOccurs may now be greater than 1 on particles in anall group. The elements which match a particular particle need not be adjacent in the input.
3. all groups can now be extended by adding more members to them.
Complex types whose content models areall-groupscan now be extended; the result is anall-group(usually a larger one).
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 theUnique Particle Attribution (§3.8.6.4) have in any case rendered those algorithms obsolete. These changes resolve issue6685 Appendix I Checking content-type restriction References Not Available.
Group references are now allowed in<xs:all> model groups. Such referencesmust haveminOccurs=maxOccurs=1 andmust refer to other<xs:all> groups. (This change resolves issue 7031 XSD 1.1 doesn't support conversion of xs:sequence to xs:all because xs:all can't contain groups references.)

G.1.4 Assertions and XPath

Assertions and rules for evaluation of XPaths

Support for check clauses toimplement some co-occurrence constraints has been added. Eachcomplex type can carry a list of assertions, which are checkedwhen the complex type is used to validate an elementinformation item.
The facility for assertions defined in the working draft of 31 August 2006 has been revised.
1. Thereport element described in earlier drafts has been removed. This involves no loss of functionality: the same effect can be obtained by wrapping the test expression on an<assert> element in a negation.
2. 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 inidentity-constraint definitions).
1. The static and dynamic contexts for XPath evaluation are explicitly specified.
2. Rules are provided for constructing the[XDM] data model instance against which the XPath expressions are to be evaluated. Different rules apply in different situations:
  1. 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.
  2. 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.
  3. For assertions on simple types, only the value is provided; the dynamic context includes no context item.
3. Rules for assigning types to the nodes of the data model instance are defined. Again, the rules differ for the different uses of XPaths:
  1. 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).
  2. For conditional type assignment, the nodes of the data model instance are untyped.
The conceptual overview now included inConstraint Components (§2.2.4) some discussion of the overlap in functionalityamong identity constraints, conditional type assignment,and assertions, and identifies some of the factorswhich may be relevant in choosing among them; thischange resolves issue5023Relationship between identity constraints and assertions.
The rules for the "available collections" and "default collection" properties of the[XPath 2.0]dynamic context have been simplified; these properties are now required to be the empty set instead of being·implementation-defined·. This improves interoperability and resolves issue6540 Available documents in assertions.
The[XPath 2.0]static context used for the evaluation of assertions has been clarified; it nowexplicitly includes the functions in the[Functions and Operators]fn namespace and constructors for all built-in types. This resolves issue6541 Assertions and in-scope functions.

G.1.5 Derivation of complex types

Derivation of complex types:

The rules for checking validity of complex-type restrictionshave been simplified by reformulating the constraint in termsof local validity: the set of elements or attributes acceptedby a restriction as locally valid must be a subset of those accepted by itsbase type. The rules for attributes have also been changed.
The complex rules involving matching up particles in the base typeand particles in the restriction, with their complex case bycase analysis, have been replaced by a statement of theconstraint which is shorter and more correct.
It is now possible to specify a target namespace forlocal elements and attributes which differs from the targetnamespace of the schema document itself, when restrictinga complex type which has local elements or attributes andwhich itself is in another namespace. This shouldsimplify the reuse of types from other namespaces.
The rules for complex type restriction now allow identityconstraints on local elements. To make this possible,identity constraints may now be given names and referred tofrom elsewhere. Corresponding changes have been made in thedescription of theSchema component and in therules for·QName resolution·.
This draft clarifies the rule requiring that any complextype derived by extension could, in principle, be derived inthree steps from·xs:anyType· (first a restriction step,then an extension step, then a restriction step). Amisleading note about the purpose of this rule has beendeleted.

G.1.6 Changes to complex type definitions

Complex type definitions (miscellaneous changes):

Changes have been made toLocally Declared Type (§3.4.4.1),Element Locally Valid (Complex Type) (§3.4.4.2), andDerivation Valid (Restriction, Complex) (§3.4.6.3) to require more consistency in type assignment when elements with the same expanded name may match both a local element declaration and a wildcard in the same content model. Conceptually, these changes are related to the constraint expressed inElement Declarations Consistent (§3.8.6.3). XSD 1.0 allows such content models even if there is a discrepancy between the type assigned to elements by the local element declarations and by the top-level element declaration which will govern elements which match the wildcard. For compatibility reasons, such content models are still allowed, but any element instance which matches the wildcard is required to have a governing type definition compatible with the type assigned by the local element declarations matched by the element's expanded name.
The elements<complexType> and<complexContent>are now forbidden to have different values for themixedattribute.
The constraintElement Declarations Consistent (§3.8.6.3) now takes open content into account. This change, together with the explicit exclusion of skip wildcards from the constraint, resolves issue5940 Element Declarations Consistent.
The rules for restriction of complex types containing local elements with conditional types have been simplified; this resolves issue12185 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·implementation-defined· when type errors in XPath expressions are detected and whether they are treated as static or dynamic errors. This change resolves issue11073 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 issue12127 "Root element" in assertion testing.

G.1.7 ID, IDREF, and related types

ID, IDREF, and related types:

Certain constraints involvingID have beenextended to include lists ofID and unions includingID. See e.g.Constraints on Attribute Declaration Schema Components (§3.2.6).
An element may now have multiple attributes of typexs:ID. Elements have always been able to havemultiple children of typexs:ID, but XSD 1.0 forbadmultiple attributes of this type for compatibilitywith XML DTDs. (Schemas intended to be translatable into DTDform should still avoid the practice.) This change should makeit easier for XML vocabularies to support both existingID attributes andxml:ID.
The validation rules for values of typexs:IDREF,xs:ENTITY, orxs:ENTITIESare now enforced on default values.
Elements and attributes of typexs:ID may now havedefault or fixed values. XSD 1.0 had forbidden this, forcompatibility with XML DTDs.
The text has been revised to ensure that the special validation rules forxs:ID,xs:IDREF,xs:IDREFS,xs:ENTITY, andxs: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 issue10662 Should IDREFS and ENTITIES be magic types?.

G.1.8 Simple type definitions

Changes involving simple type definitions and related constraints:

A new type definition calledanyAtomicType has been introduced into the typehierarchy betweenanySimpleType and all theatomic built-in type definitions. SeeBuilt-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 ruleType Derivation OK (Simple) (§3.16.6.3) has been modified to ensure that member types are not·validly substitutable· for facet-restricted unions. As a result,xsi:type may no longer be used, as in XSD 1.0, to subvert restrictions of union types.
The requirement that a facet value be a "valid restriction" of another, in the context of simpletype 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 forbadunion datatypes to be members of other unions and thus hadno need to forbid this explicitly.)
Since not all datatypes have adefined canonical representation for all of their values,appeals to the canonical forms of values have beeneliminated.
Changes have been made to ensure thatthe descriptions of theSimple Type Definition component and of·xs:anySimpleType· agree in alldetails with those of[XML Schema: Datatypes].
Equality and identity of lists have been clarified.
The fact that·xs:anyType· is its own base typehas been clarified (addresses issue6204 anyType/ur-Type: inconsistent whether it has a base-type).
Enumerations, value constraints, and identity constraints now accepteither equalor identical values as the same. This change resolves issue9196 Enumeration and NaN
Changes have been made in sectionConstraints on XML Representations of Simple Type Definitions (§3.16.3) and sectionConstraints 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 issue11222 src-simple-type.1 should allow duplicate elements from "##other" namespaces.

G.1.9 Element declarations

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 (typicallyattribute values). The addition of conditional type assignmenthas entailed a number of changes:
1. Introduction of aType Table property on element declarations, to hold a sequence ofType Alternatives (condition - selected-type pairs) and a default type definition.
2. Constraints on that table: all types named in the table (including the default) must be·validly substitutable· for the declared{type definition}.
3. Changes to the XML syntax and XML mapping rules to allow expression of conditional type bindings: the<alternative> element is added, the content model of<element> is changed.
4. Validation rules for conditional types: the definition of·governing type definition· is adjusted to account for conditional type assignment.
5. 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).
6. 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·selected type definition· rather than to either the declared{type definition} or to the·governing type definition· of the element information item
7. Introduction of some terminology for discussing conditional types (define·selected type definition·,·conditionally selects·,·validly substitutable as a restriction·).
8. Rules for checking type restriction in the presence of conditional types.
9. Introduction of a special·xs:error· type for use in identifying conditionally assigned types which violate restriction rules
10. Miscellaneous supporting editorial changes.
Element declarations may now specify multiple substitution-groupheads.
Abstract elements may now appear in substitution groups.
The treatment of type tables inElement Declarations Consistent (§3.8.6.3) has been made more specific; this resolves issue11076 Element Declarations Consistent: comparing type tables.

G.1.10 Attribute declarations

Attributes:

Attribute declarations can now be marked{inheritable}(seeInherited Attributes (§3.3.5.6))and the values of inherited attributes are accessible in the XDMdata model instance constructed for conditional type assignment(seeType Alternatives (§3.12)).
Among other consequences, this allows conditional type assignment to be sensitive to the inherited value ofthexml:lang attribute and thus to the language ofthe element's contents. This change was introduced to resolve issue5003 Applicability of <alternative> element to xml:lang,raised by theW3C Internationalization Core Working Group.
The rules for default attribute values now refer to the·effective value constraint·,rather than to the[Value Constraint]; this resolves a bugin the handling of default values for global attributedeclarations.
The text now makes clear that it is pointless (althoughnot illegal) for schema documents to supply default or fixedvalues forxsi:type and other attributes in thenamespacehttp://www.w3.org/2001/XMLSchema-instance, since theywill not be applied.
Default attribute groups are now supported. The<schema> element can carry adefaultAttributes attribute, which identifies anamedAttribute Group Definition; each complex type defined inthe schema document then automatically includes thatattribute group, unless this is overridden by thedefaultAttributesApply attribute on the<complexType> element. Default attribute groupsmake it easier to specify attributes which should be acceptedby every complex type in a schema (e.g.xml:idandxml:lang).
All wildcard unions are now expressible; this change resolves issue6163 3.10.6.3 Attribute Wildcard Union.
As described inXML Mapping Rule for Named Attribute Groups (§3.6.2.1), circular references from<attributeGroup> to<attributeGroup> are now allowed; all attribute groups in the cycle of references are included.

G.1.11 Component structure

Changes in the structure of schema components:

Every component now has an{annotations} property whose value is a sequence of annotationelements and out-of-band attributes. See e.g.The Complex Type Definition Schema Component (§3.4.1).
Annotations are no longerallowed to vary in the part of a content model sharedby a complex type and its extensions. (This was neverpossible in components specified using schema documents,but was possible in "born-binary" components.)
A{context}property has been defined for the definitions of complex andof simple types; this property simplifies testing for theidentity of anonymous type definitions. See e.g.The Complex Type Definition Schema Component (§3.4.1). The {context} propertyreplaces the {scope} property found in some earlier drafts ofthis document.
TheSchema component has anadditional{identity-constraint definitions} property containing all the identityconstraints in the corresponding schema. SeeThe Schema Itself (§3.17.1) andXML Representations of Schemas (§3.17.2).
The underlying basis for thedefinition of all the different kinds of components haschanged to make use of a regular and formal tabulation oftheir properties. This has been achieved by introducingproperty records wherever version 1.0 had complexproperty values. For example instead of describing the{scope} property as having "eitherglobal or acomplex type definition" for its value, aScope property record is called for, which in turn has itsown simple properties and values. See e.g.The Element Declaration Schema Component (§3.3.1).

G.1.12 The process of validation

The process of validation:

When anxsi:type attribute appears on an element and has a QName as its value, but the QName does not resolve to a known type definition, the element is assigned a "fallback"·governing type definition· for validation. The·governing type definition· will be the·selected type definition· or the declared{type definition}, if available, and·xs:anyType· otherwise. The validation process is now explicitly defined as including the validation of the element and its descendants; processors no longer have the implicit option of skipping the element and its descendants.
Element information items which match no particle in a content model are now to be validated using their·locally declared type·. Earlier drafts did not specify what happened in such cases.
·Lax assessment· is now required when an element information item to be validated has neither a·governing element declaration· nor a·governing type definition·; also, lax assessment now requires that the[children] and[attributes] of the element be assessed as well. In XSD 1.0 and in earlier drafts, lax assessment was optional and did not require the recursive assessment of[children] and[attributes].
The text now specifies that if an element has anxsi:type attribute which does not·resolve· to a type definition, then thexsi:type attribute is invalid.
The terminology of assessment has been changed to avoid the suggestion that an element information item can be·strictly assessed· without being·assessed·.
An anomaly in the definition of·governing element declaration· has been corrected, to ensure that elements matching strict or lax wildcards have the appropriate global element declaration, if it exists, as their·governing element declaration·. (Resolves issue7913 Strange result from definition of governing element declaration.)
The usage of the terms "·validation·" and "·assessment·" has been clarified, and definitions of various forms of document validity have been added for the convenience of users of this specification; seeSchema-validity and documents (§2.5). (Resolves issues5164 validation vs assessment and6015 [schema11] valid (and its derivations) vs assessment as used in text.)
The definition ofElement 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 issue11764 Unresolved xsi:type should not affect validity against a type.

G.1.13 The·post-schema-validation infoset·

Changes in the description of the·post-schema-validation infoset·:

The presentation of the·post-schema-validation infoset· has been simplified by removing the suggestion that the·post-schema-validation infoset· varies from processor to processor. Instead, the exposition now makes clearer that the body of information available in principle after schema-validity assessment is consistent across all processors; processors may make different subsets of the·post-schema-validation infoset· accessible to downstream applications, but when they do so the variation reflects the implementors' decisions about what information to expose, not variation in the information in the·post-schema-validation infoset·.
Terms have been defined to describe different subsets of the·post-schema-validation infoset· which may be exposed by processors.
Provision is made for exposing the·actual values· of elements and attributes in the·post-schema-validation infoset·, in the{schema actual value} property.
The[element declaration] property and variousother properties in the·post-schema-validation infoset· are now described as beingpresent in the·post-schema-validation infoset· whenever a·governing· declarationand/or·governing· type definition is known for the item,instead of only when the item is valid.
When the·governing· type definition of an attribute or element information item is a list type whose item type is a union, the·post-schema-validation infoset· now includes the·validating type· for each item in the list.
When default values are supplied for attributes withqualified names,·namespace fixup· is performed to ensure that the[in-scope namespaces] property of the attribute's host element has an appropriate binding for the namespace name. It is·implementation-dependent· whether·namespace fixup· is also performed on descendants of that element so as to retain consistency of the infoset.·Namespace fixup· may also be helpful if the defaulted value is of typeQName orNOTATION; it is·implementation-dependent· whether fixup is performed for such values.
Annotations given in the XML form of identity-constraint declarations withref attributes are now retained in the·post-schema-validation infoset· form of the containing element declaration. This change resolves issue6144 annotation on IDC with a 'ref' attribute is lost.

G.1.14 Conformance

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 sectionConformance (§2.4)) conformance classes for·general-purpose validators·,·general-purpose schema-validity assessors·,·special-purpose validators·, and·other special-purpose tools·, together with terminology which may be useful in describing particular processors. This change resolves issue7695Conformance.
A checklist has been included listing ways in which conforming processors may vary from each other, and terminology has beenprovided for some of the more important properties of conformingprocessors, in an attempt to make it easier for implementors todescribe concisely which options their processors exercise, andeasier for users to describe what kinds of processor they require.
The definition ofmust and·error· have been revised tospecify that conforming processorsmust detect and reporterror in the schema or schema documents. The qualityand detail of the error messages are not constrained.
Implementations are now allowed to support primitive datatypesand facets beyond those defined in[XML Schema: Datatypes].
The validity requirements for schema documents are stated morefully and correctly.

G.1.15 Schema composition

Schema assembly and composition:

The<redefine> construct is·deprecated·.
An<override> construct has been defined;in some ways it resembles<redefine>,but imposes no constraints on the new definitions providedfor components whose definitions are being overridden.
The discussion of<include> and<override> has been revised to eliminate an ambiguity in earlier versions of this spec regarding the meaning of cyclic dependencies formed by use of<include> and<override>: such cyclic dependencies are now clearly allowed and have a well defined meaning.
When anxsi:schemaLocation attribute providesinformation about a schema document location for aparticular namespace, it is no longer an error for it to beencountered after the first occurrence of an element orattribute information item in that namespace.Note, however, that if processing such anxsi:schemaLocationattribute causes new components to be added to the schema, then the new components cannot change the assessment outcome of anyinformation items already seen before the element bearing thexsi:schemaLocation attribute.
No<import> is needed in a schema document in order to refer to components in namespaceshttp://www.w3.org/2001/XMLSchema orhttp://www.w3.org/2001/XMLSchema-instance. In XSD 1.0, the examples showed no such imports, but there was no rule making it legal to omit the<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.
SectionIdentifying how to react to failure (§C.2.5) has now been added,defining the termserror andcontinuefor use in specifying what a processor does or should do when it seeks components for a given namespace in a given location but fails to find them there.
Schema processors are now explicitly recommended to providea user option to control whether the processor attempts todereference schema locations indicated inschemaLocationattributes in the instance document being validated; this resolvesissue5476 xsi:schemaLocation should be a hint, should be MAY not SHOULD.
The discussion ofschemaLocation information inHow schema definitions are located on the Web (§4.3.2) has been revised to try to make clearer the motivation for recommending user control over whether schema locations specified in the document instance should or should not be dereferenced. The new text describes some circumstances in which such schema locations typically should be dereferenced and some in which they should not, and attempts to set useful expectations for users and for implementors. These changes are intended to resolve issue6655, raised by the W3C Web Accessibility Initiative's Protocols and Formats Working Group.
The discussion of schema import inLicensing References to Components Across Namespaces (§4.2.6.1) now states more clearly that references to components in external namespaces are an error if the namespace is not imported; this change addresses issue5779 QName resolution and xs:import.
Some errors in the XSLT stylesheet of appendixTransformation for Chameleon Inclusion (§F.1) have been corrected (resolving issues8573 F.1 Stylesheet for chameleons invalid and8574 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 issues11179 minor editorial improvement : parent schema components of a named model group and11354 Mentions of "override" outside of the override section

G.1.16 Other substantive changes

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·) is now required; in earlier drafts of this document, fallback to lax validation was optional.
The XML Representation Constraints no longer refer to thecomponent level; this makes it possible to test a schemadocument in isolation to determine whether it conforms orfails 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 issue6235 Restriction from xs:anySimpleType.
The<schema> element is now declared with open content in the schema for schema documents. This change addresses issue5930 defaultOpenContent in the S4SD.
The settingblockDefault="#all" has been removed from the schema for schema documents; this change resolves issue6120 Reconsider blockDefault=#all.
Namespace fixup is now explicitly required in some places where it is needed but was not mentioned before; these changes resolve issue6445 Namespace fixup and default namespace and issue6465 Namespace fixup and inherited attributes.
In the DTD for schema documents (DTD for Schemas (non-normative) (§I)), an error has been corrected in the declaration of theinheritable attribute of thexs:attribute element (resolving issue11070 DTD for schema documents: inheritable declared as %URIref).
In the schema for schema documents, an error in the declaration ofxs:group within the named model groupxs:allModel has been corrected to make the type ofxs:all a legal restriction of its base type and make the schema for schema documents conformant to this specification. This resolves issue11092 Error in S4SD: complexType name="all" is not a valid restriction.

G.1.17 Clarifications and editorial changes

Clarifications and other editorial changes:

Each named constraint is now given in a separate section, tosimplify reference to them.
The XML mapping rules have been reorganized to make them more perspicuous.
The keywords defined by[IETF RFC 2119] to designate different levels of requirement have beenmarked up to distinguish more consistently between cases where their normative meaning isintended (e.g. "must") and cases where the words are used in its everyday sense without conformance implications (e.g. "must"). SeeDocumentation Conventions and Terminology (§1.5).
A note has been added, warning thatthereplace andcollapse valuesfor whitespace handling are not a reliable means ofneutralizing the effects of word-wrapping and pretty-printingof natural-language data and should not be used for thatpurpose.
Several minor corrections andclarifications have been made. The usage of some technicalterminology has been clarified, normalized, and aligned whereappropriate with the usage in[XML Schema: Datatypes]. Conditionals using"if" have been rephrased to use "if and only if" where appropriate.
The title of the specification has been changed, and the languagedefined here is referred to as XSD, not using the name"XML Schema". This may help reduce confusion betweenthe language defined here and the broader class of XML schemalanguages in general.
Conformance-related language has been reviewedto avoid confusion between the conformance-related usage ofthe verbsmay,must, andshould, and other usages.
Various new terms have been defined, and some existing terms havebeen redefined, to reduce confusion and improve legibility. Insome cases, existing terms which were felt insufficientlyinformative have been replaced by new terms which may be moreuseful.
Following the example of XQuery1.0 and XSLT 2.0, the terms "·implementation-defined·" and"·implementation-dependent·" have been defined and the twoconcepts distinguished. The appendix contains lists both of·implementation-defined· and of·implementation-dependent· features.
The term "context-determined-declaration" has been replaced with the term·locally declared type·; this resolves issue4690 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 issue4316 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); and6233 Wrong pointer for [nil] PSVI property.
Discussions of global components nowtake <redefine> into account (addresses issue5918 Top level declarations).
The usage of "·validation·", "·assessment·", and related terms has been clarified and made more consistent.
It has been clarified that fields of identity constraint definitions can have complex types with simple content.
The text concerningxsi:type attributes and their effect has been clarified inElement Locally Valid (Element) (§3.3.4.3). In particular, the revisions attempt to make clearer just what happens in cases where thexsi:type attribute in the document instance cannot be used (because the type named is unknown, or otherwise not usable). This resolves issue11219 Editorial revision of Element Locally Valid (Element).
The text has been revised to make clearer that declarations enclosed in anxs:override element are handled using theelementFormDefault and other schema-document-level defaults from the schema document being overridden, not the schema document containing thexs:override element. This resolves issue10652 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 issue11103 Note in section 2.4.1 (Special datatypes as members of a union).
The treatment of elements in the Schema namespace occurring within<annotation> elements has been clarified:
- 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·implementation-defined· (The Annotation Schema Component (§3.15.1),Checklist of implementation-defined features (§E.1)).
This change resolves issue10125 Validation of the content of xs:annotation.
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 issue12184 Circularity in xs:override.

G.2 Issues not resolved

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 onall groups have been relaxed;all groups, however, must still be top-level groups; they are not allowed to appear within sequences or choice groups.
The namespace-related properties of the basic infoset are·fixed up· when attributes with qualified names are assigned default values.
Other kinds of infoset fixup, however, are still not performed. Attributes of typeID,IDREF,IDREFS, andNOTATION do not have the same effect on the base infoset as they do if declared in a DTD. (An infoset-to-infoset transformation can be used to migrate the appropriate information into the base infoset.)
Some existing implementations (and specifications) assume that elements of typexs:ID uniquely identify themselves, instead of uniquely identifying their parent. This version of this specification reaffirms the existing rule, which is that elements and attributes of typexs:ID uniquely identify the parent element of the ID attribute or element.
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 constraintElement Declarations Consistent (§3.8.6.3) has been recast, but not at the higher level of abstraction originally required and expected.
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 iscurrently anticipated.

H Glossary (non-normative)

The listing below is for the benefit of readers of a printed version of thisdocument: it collects together all the definitions which appear in thedocument above.

L(D)

For anyElement DeclarationD, the languageL(D)·accepted· byD is the set of all sequences oflength 1 whose sole member is an element information item which·matches·D.

L(W)

For anyWildcardW, the languageL(W)·accepted· byWis the set of all sequences oflength 1 whose sole member is an element information item which·matches·W.

NCName

AnNCName isa name with no colon, as defined in[XML Namespaces 1.1]. When used in connection with the XMLrepresentation of schema components in this specification, this refersto the simple typeNCName as defined in[XML Schema: Datatypes]

QName

AQName is aname with an optional namespace qualification, as defined in[XML Namespaces 1.1]. When used in connection with the XMLrepresentation of schema components or references to them, this refersto the simple typeQNameas defined in[XML Schema: Datatypes]

Schema Component Constraint

Constraints on the schema components themselves, i.e. conditions componentsmust satisfy to be components at all. They are located in the sixth sub-section of the per-component sections ofSchema Component Details (§3) and tabulated inSchema Component Constraints (§B.4)

Schema Information Set Contribution

Augmentations to·post-schema-validation infoset·s expressed by schema components, which follow as a consequence of·assessment·. They are located in the fifth sub-section of the per-component sections ofSchema Component Details (§3) and tabulated inContributions 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 inSchema for Schema Documents (Structures) (normative) (§A). They are located in the third sub-section of the per-component sections ofSchema Component Details (§3) and tabulated inSchema Representation Constraints (§B.3)

Type Definition Hierarchy

Except for·xs:anyType·, every·type definition· is, by construction,either a·restriction· or an·extension· of someother type definition. The exception·xs:anyType· is a·restriction· of itself.With the exception of the loop on·xs:anyType·, the graph of these relationships formsa tree known as theType DefinitionHierarchy with·xs:anyType· as itsroot

Validation Rules

Contributions to·validation· associated with schema components. They are located in the fourth sub-section of the per-component sections ofSchema Component Details (§3) and tabulated inValidation Rules (§B.1)

Web-aware

Web-aware processors are network-enabled processors which are not only·general-purpose· but which additionallymust be capable of accessing schema documents from the World Wide Web as described inRepresentation of Schemas on the World Wide Web (§2.8) andHow schema definitions are located on the Web (§4.3.2).

XSD schema

AnXSD schema is a set of·schema components·

absent

Throughout this specification, the termabsent is used as a distinguished property value denoting absence

accept

A model groupG is said toacceptorrecognize the members ofL(G).

accept

A particleP is said toaccept orrecognize the members ofL(P). Similarly, a termTaccepts orrecognizes the members ofL(T).

actual value

With reference to any string, interpreted as denotingan instance of a given datatype, the termactual value denotes the value to which thelexical mapping of that datatype maps the string.

ancestor

Theancestors of a·type definition· are its{base type definition} and the·ancestors· of its{base type definition}.

annotation mapping

Theannotationmapping of a set of element information itemsESis a sequence of annotationsAS, with the following properties:

1For every<annotation> element information item among the[children] of any element information item inES, thereis a correspondingAnnotation component inAS.

2If any element information itemE inES has any attribute information itemsA such thatall of the following are true:

2.1A is inE.[attributes].

2.2A.[namespace name]is present and not the XSD namespace.

2.3A is not included in the[attributes] property of any annotation component described in clause1.

3AS contains no otherAnnotation components.

annotation mapping

Theannotationmapping of a single element information item is the·annotation mapping· of the singleton set containing thatelement.

anyAtomicType

There is a further special datatypecalledanyAtomicType, a·restriction· of·xs:anySimpleType·, which is the·base type definition·of all the primitive datatypes.

anySimpleType

A special·restriction· of·xs:anyType·, whose name isanySimpleType in the XSD namespace, is the root of the·Type Definition Hierarchy· for all simple type definitions.·xs:anySimpleType· has a lexical space containing all sequences of characters in the Universal Character Set (UCS) and a value space containing allatomic values and all finite-length lists ofatomic values.

assessment

the wordassessment is used to refer to the overall process of local validation, recursive determination of validation outcome, and infoset augmentation, i.e. as a short form for "·schema-validity assessment·"

assessor

Aschema-validity assessor (or justassessor) is a processor which performs full or partial·schema-validity assessment· of an XML instance document, element information item, or attribute information item, with reference to a conforming schema, and provides access to the entirety of the resulting·post-schema-validation infoset·. The means by which an·assessor· provides access to the·post-schema-validation infoset· is·implementation-defined·.

attributed to

During·validation· of an element information item against its (complex)·governing type definition·, associations between element and attribute information items among the[children] and[attributes] on the one hand, and the attribute uses, attribute wildcard, particles and open content property record on the other, are established. The element or attribute information item isattributed to the corresponding component.

automatically known

A type about which a processor possesses prior knowledge, and which the processor can support without any declaration of thetype being supplied by the user, is said to beautomatically knownto the processor.

base particle

Let thebase particle be the particle of the{content type} of the{base type definition}.

base information set properties

Bybase information set properties are meant the properties listed inRequired Information Set Items and Properties (normative) (§D).

base type definition

The type definition used as the basisfor an·extension· or·restriction· isknown as thebase type definition of thatdefinition

basic particle

Abasic particle is aParticle whose{term} is a·basic term·.

basic term

Abasic term is anElement Declaration or aWildcard.

compete

TwoParticlesP₁ andP₂ contained in someParticlePcompete with each other if and only if some sequenceSof element information items has two·paths· inP which areidentical except that one path hasP₁ as its last item and the otherhasP₂.

competing paths

Two(or more)·paths· of a sequenceS in aParticleParecompeting paths if and only ifthey are identical except for their final items, which differ.

complete path

Fora model groupM and a sequenceS inL(M), the pathofS inM is acomplete path; prefixes ofcomplete paths which are themselves not complete pathsareincomplete paths.

component name

Declarations and definitionsmay and in some casesmust have and be identified bynames, which are NCNames as defined by[XML Namespaces 1.1]

conditionally selects

Given aType TableT and an elementinformation itemE,Tconditionally selects atypeS forE in the following way. The{test} expressions inT's{alternatives} are evaluated, in order, until one of theType Alternatives·successfully selects· a type definition forE, or until all have been tried without success. If anyType Alternative ·successfully selects· a type definition, none of the followingType Alternatives are tried. Then the typeSconditionally selected forE byT isas described in the appropriatecase among the following:

1 If at least oneType Alternative inT.{alternatives}·successfully selects· a type definition forE, thenS is the type definition selected by the first suchType Alternative.

2 If noType Alternative inT.{alternatives}·successfully selects· a type definition, thenS isT.{default type definition}.{type definition}.

constructed

Datatypes can beconstructed from other datatypes byrestricting the value space or lexical space of a{base type definition} using zero or moreConstraining Facets, by specifying the new datatype as alist of items of some{item type definition}, or by defining it as aunion of some specified sequence of{member type definitions}.

contains

A model groupcontains the components which it either·directly contains·or·indirectly contains·.

contains

A particlecontains the components which it either·directly contains·or·indirectly contains·.

content model

Aparticle can be used in a complex type definition toconstrain the·validation· ofthe[children] of an element information item; such aparticle is called acontent model

context-determined declaration

During·validation·, associations between element and attribute information items among the[children] and[attributes] on the one hand, and element and attribute declarations on the other, are also established. When an item is·attributed· to an·element particle·, then it is associated with the declaration which is the{term} of the particle. Similarly, when an attribute information item is·attributed to· anAttribute Use, then the item is associated with the{attribute declaration} of thatAttribute Use. Such declarations are called thecontext-determined declarations.

declaration

declaration components are associated by (qualified) name to information items being·validated·

declared entity name

A string is adeclared entity name if and only if it is equal to the[name] of some unparsed entity information item in the value of the[unparsedEntities] property of the document information item at the root of the infoset containing the element or attribute information item whose·normalized value· the string is.

default binding

When a sequence of element information itemsES is·locally valid· with respect to aContent TypeCT or when a set of attribute information itemsAS satisfies clause2 and clause3 ofElement Locally Valid (Complex Type) (§3.4.4.2) with respect to aComplex Type Definition, there is a (partial) functional mapping from the element information itemsE in the sequenceES or the attribute information items inAS to adefault binding for the item, where the default binding is anElement Declaration, anAttribute Use, or one of the keywordsstrict,lax, orskip, as follows:

1When the item has a·governing element declaration·, the default binding is thatElement Declaration.

2 When the item has a·governing attribute declaration· and it is·attributed· to anAttribute Use, the default binding is thatAttribute Use.

6When the item is·attributed· to askip·wildcard particle· or attribute wildcard or anOpen Content with askipWildcard then the default binding is the keywordskip.

defaulted attribute

Adefaulted attribute belonging to an element information itemE·governed by· a complex typeTis anyAttribute UseUfor whichall of the following are true:

1U is a member ofT.{attribute uses}.

2U.{required} =false.

3U's·effective value constraint· is not·absent·.

4U.{attribute declaration} is not one of theAttribute Declarations fromBuilt-in Attribute Declarations (§3.2.7).

5U.{attribute declaration} does not match any of the attribute information items inE.[attributes] as per clause2.1 ofElement Locally Valid (Complex Type) (§3.4.4.2) above.

definition

definition components define internal schema components that can be used in other schema components

definition of anyType

A special complex typedefinition, (referred to in earlier versions of this specification as 'the ur-type definition') whosename isanyType in the XSD namespace, ispresent in each·XSD schema·. Thedefinition ofanyType serves as defaulttype definition for element declarations whose XMLrepresentation does not specify one

derived

If a type definitionD can reach a type definitionB by following its base type definition chain, thenD is said to bederived fromB.

directly contains

A model groupdirectly contains the particles in the value of its{particles} property.

directly contains

A particledirectly contains the component which is the value of its{term} property.

effective value constraint

Theeffective value constraint of an attribute useU isU.{value constraint}, if present, otherwiseU.{attribute declaration}.{value constraint}, if present, otherwise theeffective value constraint is·absent·.

element particle

Anelement particle is aParticle whose{term} is anElement Declaration.

element substitution group

Through the mechanism ofelement substitutiongroups, XSD provides a more powerful model than DTDs dosupporting substitution of one named element foranother

equivalent type alternative

AnyType Alternative isequivalent to itself.Otherwise, anyType AlternativeT1 isequivalent to a differentType AlternativeT2 if and only ifT1.{test} andT2.{test} are true for the sameset of input element information itemsandT1.{type definition} andT2.{type definition} acceptthe same set of input information items as valid.In the general case, equivalence and non-equivalencecan be difficult to establish.It is·implementation-defined· under just what conditions aprocessor detects that two typealternatives are equivalent, but allprocessorsmust detectT1 andT2 asequivalent ifall of the following are true:

2T1.{test}.{default namespace} andT2.{test}.{default namespace} either are both·absent· or have the same value.

3T1.{test}.{base URI} andT2.{test}.{base URI} either are both·absent· or have the same value.

4T1.{test}.{expression} andT2.{test}.{expression} have the same value.

5T1.{type definition} andT2.{type definition} are the same type definition.

A processormay treat two type alternatives as non-equivalent if they do not satisfy the conditions justgiven and the processor does not detect that theyare nonetheless equivalent.

equivalent type table

AType TableT1 isequivalent to aType TableT2 if and only ifall of the following are true:

1T1.{alternatives} has the same length asT2.{alternatives} and their corresponding entries are·equivalent·.

2T1.{default type definition} andT2.{default type definition} are·equivalent·.

extension

A complextype definition which allows element or attribute content inaddition to that allowed by another specified type definitionis said to be anextension

field subset of XPath

The subset of XPath defined inFields Value OK (§3.11.6.3) is called thefield subset of XPath.

final

the complex type is said to befinal, because nofurther·derivations· are possible

full instance subset

Thefull instance subset of the PSVI includes almost allproperties defined by this specification as applying toelement and attribute information items, but excludes schema components. Itconsists ofthe·instance-validity subset·, plus the following properties for elements:

general-purpose

Ageneral-purpose processor is a·validator· or·assessor· which accepts schemas represented in the form of XML documents as described inLayer 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·assessed· in a given assessment episode is said togovern the item, or to be itsgoverning element or attribute declaration. Similarly the type definition with respect to which the type-validity of an item is assessed is itsgoverning type definition.

governing attribute declaration

In a given schema-validity·assessment· episode, the·governing· declaration of an attribute (itsgoverning attribute declaration) is the first of the following which applies:

1A declaration which was stipulated by the processor (seeAssessing Schema-Validity (§5.2)).

2Its·context-determined declaration·;

3A declaration·resolved· to by its[local name] and[namespace name], provided the attribute is not·skipped· and the processor has not stipulated a type definition at the start of·assessment·.

If none of these applies, the attribute has no·governing attribute declaration· (or, in equivalent words, the·governing attribute declaration· is·absent·).

governing element declaration

Thegoverning element declaration ofan element information itemE, in a given schema-validity·assessment· episode, is the first of the followingwhich applies:

1A declaration stipulated by the processor (seeAssessing Schema-Validity (§5.2)).

2E's·context-determined declaration·.

3A declaration·resolved· to byE's[local name] and[namespace name], provided thatE is·attributed· either to astrict·wildcard particle· or to alax·wildcard particle·.

4A declaration·resolved· to byE's[local name] and[namespace name], provided thatnone of the following is true:

4.1E is·skipped·

4.2the processor has stipulated a type definition forE

4.3a·non-absent··locally declared type· exists forE

If none of these applies,E hasno·governing element declaration· (or, in equivalent words,E's·governing element declaration· is·absent·).

governing type definition

Thegoverning type definition of an element information itemE, in a given schema-validity·assessment· episode, is the first of the following which applies:

1An·instance-specified type definition· which·overrides· a type definition stipulated by the processor (seeAssessing Schema-Validity (§5.2)).

2A type definition stipulated by the processor (seeAssessing Schema-Validity (§5.2)).

3An·instance-specified type definition· which·overrides· the·selected type definition· ofE.

4The·selected type definition· ofE.

5The value·absent· ifE is·skipped·.

6 An·instance-specified type definition· which·overrides· the·locally declared type·.

7The·locally declared type·.

8An·instance-specified type definition·.

If none of these applies, there is no·governing type definition· (or, in equivalent words, it is·absent·).

governing type definition

Thegoverning type definition of an attribute, in a given schema-validity·assessment· episode, is the first of the following which applies:

1A type definition stipulated by the processor (seeAssessing Schema-Validity (§5.2)).

2The{type definition} of the·governing attribute declaration·.

If neither of these applies, there is no·governing type definition· (or, in equivalent words, it is·absent·).

grouping

Agrouping of a sequence is a set of sub-sequences, some orall of which may be empty, such that each member of the originalsequence appears once and only once in one of the sub-sequences andall members of all sub-sequences are in the originalsequence.

implementation-defined

Animplementation-defined feature or behaviormay vary among processors conforming to this specification; the precise behavior is not specified by this specification butmust be specified by the implementor for each particular conforming implementation.

implementation-dependent

Animplementation-dependent feature or behaviormay vary among processors conforming to this specification; the precise behavior is not specified by this or any other W3C specification and is not required to be specified by the implementor for any particular implementation.

implicitly contains

A listof particlesimplicitly contains an element declaration if and only if amember of the list contains thatelement declaration in its·substitution group·

indirectly contains

A model groupindirectly contains the particles, groups, wildcards, andelement declarations which are·contained· by the particles it·directly contains·.

indirectly contains

A particleindirectly contains the particles, groups, wildcards, andelement declarations which are contained by the value of its{term} property.

initial value

theinitial value of someattribute information item is the value of the[normalizedvalue] property of that item. Similarly, theinitial value of an element information item is the string composed of, in order, the[character code] of each character information item in the[children] of thatelement information item

instance-specified type definition

Aninstance-specified type definition is a type definition associated with an element information item in the following way:

1Among the element's attribute information items is one namedxsi:type.

2The·normalized value· of that attribute information item is a qualified name·valid· with respect to the built-inQName simple type, as defined byString Valid (§3.16.4).

3The·actual value· (a·QName·)·resolves· to a type definition. It is this type definition which is theinstance-specified type definition.

instance-validity subset

Theinstance-validity subset of the PSVI consists ofthe·root-validity subset·, plus the following properties on elements,wherever applicable:

item isomorphic to a component

by anitem isomorphic to a component is meantan information item whose type is equivalent to the component's, withone property per property of the component, with the same name, andvalue either the same atomic value, or an information itemcorresponding in the same way to its component value, recursively, asnecessary

laxly assessed

The schema validity of an element information itemE is said to belaxly assessed if and only ifboth of the following are true:

1E has neither a·governing element declaration· nor a·governing type definition·.

locally declared type

EveryComplex Type Definition determines a partial functional mapping fromelement or attributeinformation items (and theirexpanded names) to typedefinitions. This mapping serves as alocally declared type for elements and attributes which are allowed bytheComplex Type Definition.

locally declared type

For a givenComplex Type DefinitionCTD and a given attributeinformation itemA, the·locally declared type· ofA withinCTD isthe appropriatecase among the following:

1IfCTD is·xs:anyType· ,then·absent·.

2IfA has the sameexpanded name as some attribute declarationD which is the{attribute declaration} of someAttribute Use contained byCTD's{attribute uses} ,then the{type definition} ofD.

3otherwise the·locally declared type· ofA withinCTD.{base type definition}.

locally declared type

For a givenComplex Type DefinitionCTD and a given element information itemE, the·locally declared type· ofE withinCTD is the appropriatecase among the following:

1IfCTD is·xs:anyType· ,then·absent·.

3otherwise the·locally declared type· ofE withinCTD.{base type definition}.

locally valid

A sequence of element information items islocally valid with respect to aContent Type if and only if it satisfiesElement Sequence Locally Valid (Complex Content) (§3.4.4.3) with respect to thatContent Type.

locally valid

A sequenceS ofelement information items islocally valid againsta particleP if and only ifS has a·validation-path· inP. The set of all such sequences is writtenV(P).

An element information itemEmatches anElement DeclarationD if and only ifone of the following is true:

1E andD have the sameexpanded name,

2Theexpanded name ofE·resolves· to an elementdeclarationD₂ which is·substitutable·forD.

Anexpanded nameEmatches an·NCName·N anda namespace nameNS (or, equivalently,N andNSmatchE)if and only if all of the followingare true:

The local name ofE is identical toN.
Either the namespace name ofE is identical toNS,or elseE has no namespace name (E is an unqualifiedname) andNS is·absent·.

An element information itemEmatches aWildcardW (or a·wildcard particle· whose{term} isW)if and only ifEis locally·valid· with respect toW, as defined in the validation ruleItem Valid (Wildcard) (§3.10.4.1).