2.2.1 Type Definition Components

The abstract model provides two kinds of type definition component: simpleand complex.

[Definition:]  This specification usesthe phrasetype definition in cases where no distinctionneed be made between simple and complex types.

Type definitions form a hierarchy with a single root. The subsections below first describe characteristics of thathierarchy, then provide an introduction to simple and complex type definitions themselves.

2.2.2 Declaration Components

There are three kinds of declaration component: element, attribute, andnotation. Each is described in a section below. Also included is a discussionof element substitution groups, which is a feature provided in conjunction withelement declarations.

<!ELEMENT A . . .><!ATTLIST A . . .>

2.2.3 Model Group Components

The model group, particle, and wildcard components contribute tothe portion of a complex type definition that controls an elementinformation item's content.

2.2.4 Identity-constraint Definition Components

An identity-constraint definition is an association between a name and one ofseveral varieties ofidentity-constraint related to uniqueness and reference. All thevarieties use[XPath] expressions to pick out sets ofinformation items relative to particular target elementinformation items which are unique, or a key, or a·valid· reference, withina specified scope. An element information item is only·valid· withrespect to an element declarationwith identity-constraint definitions if those definitions are all satisfied for all the descendantsof that element information item which they pick out.

For detailed information on identity-constraint definitions, seeIdentity-constraint Definitions (§3.11).

2.2.5 Group Definition Components

There are two kinds of convenience definitions provided to enablethe re-use of pieces of complex type definitions: model group definitionsand attribute group definitions.

2.2.6 Annotation Components

An annotation is information for human and/or mechanicalconsumers. The interpretation of such information isnot defined in this specification.

For detailed information on annotations, seeAnnotations (§3.13).

2.6.1 xsi:type

TheSimple Type Definition (§2.2.1.2) orComplex Type Definition (§2.2.1.3) used in·validation· of an element is usuallydetermined by reference to the appropriate schema components.An element information item in an instance may, however,explicitly assert its type using the attributexsi:type.The value of this attribute is a·QName·; seeQName Interpretation (§3.15.3) forthe means by which the·QName· isassociated with a type definition.

2.6.2 xsi:nil

XML Schema: Structures introduces a mechanism for signaling that an element shouldbe accepted as·valid· when it has nocontent despite a content type which does not require or even necessarily allow empty content. Anelement may be·valid· without content if it has the attributexsi:nil withthe valuetrue. An element so labeled must be empty, but cancarry attributes if permitted by the corresponding complex type.

2.6.3 xsi:schemaLocation, xsi:noNamespaceSchemaLocation

Thexsi:schemaLocation andxsi:noNamespaceSchemaLocation attributes can be used in a document to providehints as to the physical location of schema documents which may be used for·assessment·.SeeHow schema definitions are located on the Web (§4.3.2) for details on the use of these attributes.

3.1.1 Components and Properties

Components are defined in terms of theirproperties, and each property in turn is defined by giving its range,that is the values it may have. This can be understood asdefining a schema as a labeled directed graph, where the root is a schema,every other vertex is a schemacomponent or a literal (string, boolean, number) and every labeled edge is aproperty. The graph isnot acyclic: multiple copies ofcomponents with the same name in the same·symbol space· may not exist, so in some cases re-entrant chainsof properties must exist. Equality of components for the purposes of thisspecification is always defined as equality of names (including targetnamespaces) within symbol spaces.

[Definition:]  Throughout this specification, thetermabsent is used as a distinguished property value denoting absence.

Any property notidentified as optional is required to be present; optional properties which arenot present are taken to have·absent· as their value. Anyproperty identified as a having a set, subset or list value may have an empty value unless this is explicitlyruled out: this isnot the same as·absent·. Any property value identified as a superset or subset of some set may be equal to that set, unless a proper superset or subset is explicitly called for.By 'string' in Part 1 of this specification is meant asequence of ISO 10646 characters identified aslegal XML charactersin[XML 1.0 (Second Edition)].

3.1.2 XML Representations of Components

The principal purpose ofXML Schema: Structures is to define a set of schema components that constrain the contents of instances and augment the information sets thereof. Although no external representationof schemas is required for this purpose, such representations willobviously be widely used. To provide for this in an appropriate andinteroperable way, this specification provides a normative XML representation for schemas whichmakes provision for every kind of schemacomponent.[Definition:]  A document inthis form (i.e. a<schema> element information item) is aschema document. For the schema document as a whole, andits constituents, the sections below define correspondences between elementinformation items (with declarations inSchema for Schemas (normative) (§A) andDTD for Schemas (non-normative) (§G)) andschema components. All the element information items in the XML representationof a schema must be in the XML Schema namespace, that is their[namespace name] must behttp://www.w3.org/2001/XMLSchema. Although a common way of creating the XML Infosets which are or contain·schema documents· will be using an XML parser, this is not required: any mechanism which constructs conformant infosets as defined in[XML-Infoset] is a possible starting point.

Two aspects of the XML representations of components presented in thefollowing sections are constant across them all:

1. All of them allow attributes qualified with namespace names other thanthe XML Schema namespace itself: these appear as annotations in thecorresponding schema component;
2. All of them allow an<annotation> as their first child, for human-readable documentation and/or machine-targeted information.

3.1.3 The Mapping between XML Representations and Components

For each kind of schema component there is a corresponding normative XML representation.The sections below describe the correspondences between the properties of each kind ofschema component on the one hand and the properties of information items inthat XML representation on the other, togetherwith constraints on that representation above and beyond those implicit in theSchema for Schemas (normative) (§A).

The language used is as if the correspondences were mappings from XML representation toschema component, but the mapping in the other direction, and therefore thecorrespondence in the abstract, can always beconstructed therefrom.

In discussing the mapping from XML representations to schemacomponents below, the value of a component property is often determined by thevalue of an attribute information item, one of the[attributes] of an elementinformation item. Since schema documents are constrained by theSchema for Schemas (normative) (§A), there is always a simple typedefinition associated with any such attribute information item.[Definition:]  Thephraseactual value is used to refer to the member of the value space of thesimple type definition associated with an attribute information item which corresponds toits·normalized value·. This will often be a string, but may also be aninteger, a boolean, a URI reference, etc. This term is also occasionally used with respect to element or attribute information items in a document being·validated·.

Many properties are identified below as havingother schema components or sets of components as values. For the purposes of exposition, the definitions inthis section assume that (unless the property is explicitly identified asoptional) all such values are in fact present. When schemacomponents are constructed from XML representations involving reference by nameto other components, this assumption may be violated if one or more referencescannot be resolved. This specification addresses the matter of missingcomponents in a uniform manner, described inMissing Sub-components (§5.3): no mention ofhandling missing components will be found in the individual componentdescriptions below.

Forward reference to named definitions and declarationsisallowed, both within and between·schema documents·. By the time the component corresponding to an XML representation whichcontains a forward reference is actually needed for·validation· an appropriately-named component may have become available to discharge the reference: seeSchemas and Namespaces: Access and Composition (§4) for details.

3.1.4 White Space Normalization during Validation

Throughout this specification,[Definition:]  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.

The above definition means that comments and processing instructions,even in the midst of text, are ignored for all·validation· purposes.

[Definition:]  Thenormalized value of an element orattribute information item is an·initial value· whose white space, if any, has beennormalized according to the value of thewhiteSpace facet of thesimple type definition used in its·validation·:

preserve

No normalization is done, the value is the·normalized value·

replace

All occurrences of#x9 (tab),#xA (line feed) and#xD (carriage return) are replaced with#x20 (space).

collapse

Subsequent to the replacements specified above underreplace,contiguous sequences of#x20s are collapsed to a single#x20, and initial and/or final#x20s are deleted.

If the simple type definition used in an item's·validation· is the·simple ur-type definition·, the·normalized value· must be determined as in thepreserve case above.

There are three alternative validation rules which may supply thenecessary background for the above:Attribute Locally Valid (§3.2.4) (clause3),Element Locally Valid (Type) (§3.3.4) (clause3.1.3) orElement Locally Valid (Complex Type) (§3.4.4) (clause2.2).

These three levels of normalization correspond to the processing mandatedin XML 1.0 for element content, CDATA attribute content and tokenizedattributed content, respectively. SeeAttribute Value Normalization in[XML 1.0 (Second Edition)] for the precedent forreplace andcollapse for attributes. Extending this processing to element content is necessary to ensure a consistent·validation· semantics for simple types, regardless of whether they are applied to attributes or elements. Performing it twice in the case of attributes whose[normalizedvalue] has already been subject to replacement or collapse on the basis ofinformation in a DTD is necessary to ensure consistent treatment of attributesregardless of the extent to which DTD-based information has been made use ofduring infoset construction.

3.2.1 The Attribute Declaration Schema Component

The attribute declaration schema component has the followingproperties:

The{name} property must match the local part of the names of attributes being·validated·.

The value of the attribute must conform to the supplied{type definition}.

A non-·absent· value of the{target namespace} property provides for·validation· ofnamespace-qualified attribute information items (which must be explicitlyprefixed in the character-level form of XML documents).·Absent· values of{target namespace}·validate· unqualified (unprefixed) items.

A{scope} ofglobal identifies attribute declarationsavailable for use in complex type definitions throughout the schema. Locally scoped declarations are available for use only within thecomplex type definition identified by the{scope} property. This property is·absent· in the case of declarations within attribute group definitions: their scope will be determined when they are used in the construction of complex type definitions.

{value constraint} reproduces the functions of XML 1.0 default and#FIXEDattribute values.default specifies that the attribute is to appear unconditionally inthe·post-schema-validation infoset·, with the supplied value usedwhenever the attribute is not actually present;fixed indicates that the attribute value if present must equal the suppliedconstraint value, and if absent receives the supplied value as fordefault. Note that it isvalues that are supplied and/orchecked, not strings.

SeeAnnotations (§3.13) for information on the role of the{annotation} property.

[XML-Infoset] distinguishes attributes with names such asxmlns orxmlns:xsl fromordinary attributes, identifying them as[namespace attributes]. Accordingly, it is unnecessary and in fact not possible forschemas to contain attribute declarations corresponding to suchnamespace declarations, seexmlns Not Allowed (§3.2.6). No means is provided inthis specification to supply adefault value for a namespace declaration.

3.2.2 XML Representation of Attribute Declaration Schema Components

The XML representation for an attribute declaration schema component is an<attribute> element information item. It specifies a simple typedefinition for an attribute either by reference or explicitly, and may provide default information. The correspondences between theproperties of the information item andproperties of the component are as follows:

Attribute declarations can appear at the top level of a schema document, or within complextype definitions, either as complete (local) declarations, or by reference to top-leveldeclarations, or within attribute group definitions. For complete declarations, top-level or local, thetype attribute is used when the declaration can use abuilt-in or pre-declared simple type definition. Otherwise ananonymous<simpleType> is provided inline.

The default when no simple type definition is referenced orprovided is the·simple ur-type definition·, which imposes no constraints at all.

Attribute information items·validated· by a top-level declaration must be qualified with the{target namespace} of that declaration (if this is·absent·, the item must be unqualified). Control over whether attribute information items·validated· by a local declaration must be similarly qualified or notis provided by theform[attribute], whose default is providedby theattributeFormDefault[attribute] on the enclosing<schema>, via its determination of{target namespace}.

The names for top-level attribute declarations are in their own·symbol space·. The names of locally-scopedattribute declarations reside in symbol spaces local to the type definition which containsthem.

3.2.3 Constraints on XML Representations of Attribute Declarations

3.2.4 Attribute Declaration Validation Rules

3.2.5 Attribute Declaration Information Set Contributions

3.2.6 Constraints on Attribute Declaration Schema Components

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

3.2.7 Built-in Attribute Declarations

There are four attribute declarations present in everyschema by definition:

3.3.1 The Element Declaration Schema Component

The element declaration schema component has the followingproperties:

The{name} property must match the local part of the namesof element information items being·validated·.

A{scope} ofglobal identifies element declarations available for use in contentmodels throughout the schema. Locally scoped declarations are available for use only within thecomplex type identified by the{scope} property. This property is·absent· in the case of declarations within named model groups: their scope is determined when they are used in the construction of complex type definitions.

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

An element information item is·valid·if it satisfies the{type definition}. For such anitem, schema information set contributions appropriate to the{type definition} are added to thecorresponding element information item in the·post-schema-validation infoset·.

If{nillable} istrue, then an element mayalso be·valid· if itcarries the namespace qualified attribute with[local name]nil from namespacehttp://www.w3.org/2001/XMLSchema-instance and valuetrue (seexsi:nil (§2.6.2)) even if it hasno text or element content despite a{content type} which wouldotherwise require content. Formal details of element·validation· are described inElement Locally Valid (Element) (§3.3.4).

{value constraint} establishes a default or fixed value for an element. Ifdefault is specified, and if the elementbeing·validated· is empty, then thecanonical form of the suppliedconstraint value becomes the[schema normalized value] of the·validated· element in the·post-schema-validation infoset·. Iffixed is specified, then the element's contentmust either be empty, in which casefixed behaves asdefault,or its value must match the supplied constraint value.

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

Element declarations are potential members of the substitution group, if any, identifiedby{substitution group affiliation}. Potential membership is transitive but not symmetric; an elementdeclaration is a potential member of any group of which its{substitution group affiliation} is a potential member. Actual membership may be blocked by the effects of{substitution group exclusions} or{disallowed substitutions}, see below.

An empty{substitution group exclusions} allows a declaration to be nominated asthe{substitution group affiliation} of other element declarations having the same{type definition} ortypes derived therefrom. The explicitvalues of{substitution group exclusions} rule out element declarations having types whichareextensions orrestrictions respectively of{type definition}. Ifboth values are specified, then the declaration may not be nominated as the{substitution group affiliation} of any other declaration.

The supplied values for{disallowed substitutions} determinewhether an element declaration appearing in a·content model· will be prevented from additionally·validating· elements (a) with anxsi:type (§2.6.1) that identifies anextension orrestriction of the type of the declared element, and/or (b) from·validating· elements which are in thesubstitution 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 incontent models only when substitution is allowed;such declarations may not themselves ever be used to·validate· element content.

SeeAnnotations (§3.13) for information on the role of the{annotation} 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 typedefinition for an element either by reference or explicitly, and may provideoccurrence and default information. The correspondences between theproperties of the information item andproperties of the component(s) it corresponds to are as follows:

<element> corresponds to an element declaration, and allowsthe type definition of that declaration to be specified either by reference orby explicit inclusion.

<element>s within<schema> 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 pre-declared type definition. Otherwise ananonymous<simpleType> or<complexType> is provided inline.

Element information items·validated· by a top-level declaration must be qualified with the{target namespace} of that declaration (if this is·absent·, the item must be unqualified). Control over whether element information items·validated· by a local declaration must 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}.

As noted above 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. As with attribute names, the names of locally-scopedelement declarations with no{target namespace} reside in symbol spaces local to the type definition which containsthem.

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 has the same type definition as thehead of its substitution group if it identifies one, otherwise the·ur-type definition·. 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.

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

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

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

3.3.3 Constraints on XML Representations of Element Declarations

3.3.4 Element Declaration Validation Rules

3.3.5 Element Declaration Information Set Contributions

3.3.6 Constraints on Element Declaration Schema Components

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

The following constraints define relations appealed to elsewhere in this specification.

3.4.1 The Complex Type Definition Schema Component

A complex type definition schema component has the followingproperties:

Complex types 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·XMLSchema·, 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.6.1)), and for use in the XMLrepresentation of schema components(specifically in<element>). SeeReferences to schema components across namespaces (§4.2.3) for the use of componentidentifiers when importing one schema into another.

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

Complex types for which{abstract} istrue mustnot be used as the{type definition} for the·validation· of element information items. It follows that they must not be referenced from anxsi:type (§2.6.1) attribute in an instance document. Abstract complex types can beused as{base type definition}s, or even as the{type definition}s of element declarations, provided in every case a concrete derived type definition is used for·validation·, either viaxsi:type (§2.6.1) or the operation of a substitution group.

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

{attribute wildcard}s provide a more flexible specification for·validation· ofattributes not explicitly included in{attribute uses}.Informally, the specific valuesof{attribute wildcard} are interpreted as follows:

• any:[attributes] can include attributes with any qualified or unqualified name.
• a set whosemembers are either namespace names or·absent·:[attributes] caninclude any attribute(s) from the specified namespace(s). If·absent· is included in the set, then any unqualified attributes are (also) allowed.
• 'not' and a namespace name:[attributes] cannot include attributes from the specified namespace.
• 'not' and·absent·:[attributes] cannot includeunqualified attributes.

SeeElement Locally Valid (Complex Type) (§3.4.4) andWildcard allows Namespace Name (§3.10.4) for formaldetails of attribute wildcard·validation·.

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

• A{content type} with the distinguished valueempty·validates· elementswith no character or element information item[children].
• A{content type} which is aSimple Type Definition (§2.2.1.2)·validates·elements with character-only[children].
• Anelement-only{content type}·validates· elements with[children] thatconform to the supplied·content model·.
• Amixed{content type}·validates· elements whose element[children] (i.e. specifically ignoring other[children] such as character information items)conform to the supplied·content model·.

{prohibited substitutions} determinewhether an element declaration appearing in a·content model· is prevented from additionally·validating· element items with anxsi:type (§2.6.1) attribute thatidentifies a complex type definition derived byextension orrestriction from this definition, or element items ina substitution group whose type definition is similarly derived:If{prohibited substitutions} is empty,then all such substitutions are allowed, otherwise, the derivation method(s) itnames are disallowed.

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

3.4.2 XML Representation of Complex Type Definitions

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

The XML representation for complex type definitions witha simple type definition{content type} is significantly differentfrom that of those with other{content type}s, and thisis reflected in the presentation below, which displays first the elementsinvolved in the first case, then those for the second. The property mapping is shown once for each case.

Careful consideration of the above concrete syntax reveals thata type definition need consist of no more than a name, i.e. that<complexType name="anyThing"/> is allowed.

<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"/>  <width unit="cm">25</width><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"/>  <depth>   <size>25</size><unit>cm</unit>  </depth><xs:complexType name="length3"> <xs:sequence>  <xs:element name="size" type="xs:nonNegativeInteger"/>  <xs:element name="unit" type="xs:NMTOKEN"/> </xs:sequence></xs:complexType>

<xs:complexType name="personName"> <xs:sequence>  <xs:element name="title" minOccurs="0"/>  <xs:element name="forename" minOccurs="0" maxOccurs="unbounded"/>  <xs:element name="surname"/> </xs:sequence></xs:complexType><xs:complexType name="extendedName"> <xs:complexContent>  <xs:extension base="personName">   <xs:sequence>    <xs:element name="generation" minOccurs="0"/>   </xs:sequence>  </xs:extension> </xs:complexContent></xs:complexType><xs:element name="addressee" type="extendedName"/>  <addressee>   <forename>Albert</forename>   <forename>Arnold</forename>   <surname>Gore</surname>   <generation>Jr</generation>  </addressee>

<xs:complexType name="simpleName"> <xs:complexContent>  <xs:restriction base="personName">   <xs:sequence>    <xs:element name="forename" minOccurs="1" maxOccurs="1"/>    <xs:element name="surname"/>   </xs:sequence>  </xs:restriction> </xs:complexContent></xs:complexType><xs:element name="who" type="simpleName"/>   <who>    <forename>Bill</forename>    <surname>Clinton</surname>   </who>

<xs:complexType name="paraType" mixed="true"> <xs:choice minOccurs="0" maxOccurs="unbounded">  <xs:element ref="emph"/>  <xs:element ref="strong"/> </xs:choice> <xs:attribute name="version" type="xs:number"/></xs:complexType>

3.4.3 Constraints on XML Representations of Complex Type Definitions

3.4.4 Complex Type Definition Validation Rules

3.4.5 Complex Type Definition Information Set Contributions

3.4.6 Constraints on Complex Type Definition Schema Components

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

The following constraint defines a relation appealed to elsewhere in this specification.

3.4.7 Built-in Complex Type Definition

There is a complex type definition nearly equivalent to the·ur-type definition· present in everyschema by definition. It has the following properties:

Themixed content specification together with thelax wildcard and attribute specification produce the defining property for the·ur-type definition·, namely thatevery typedefinition is (eventually) a restrictionof the·ur-type definition·: its permissions and requirements are(nearly) the least restrictive possible.

3.5.1 The Attribute Use Schema Component

The attribute use schema component has the following properties:

{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 adefault or fixed value. This must 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.

3.5.2 XML Representation of Attribute Use 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

3.5.5 Attribute Use Information Set Contributions

None as such.

3.5.6 Constraints on Attribute Use Schema Components

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

3.6.1 The Attribute Group Definition Schema Component

The attribute group definition schema component has thefollowing properties:

Attribute groups are identified by their{name} and{target namespace}; attribute group identities must be unique within an·XML Schema·. SeeReferences to schema components across namespaces (§4.2.3) for the use of componentidentifiers when importing one schema into another.

{attribute uses} is a set attribute 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.13) for information on the role of the{annotation} property.

3.6.2 XML Representation of Attribute Group Definition Schema Components

The XML representation for an attribute group definition schema component is an<attributeGroup> element information item. It provides fornaming a group of attribute declarations and an attribute wildcard for use by reference in the XML representation ofcomplex type definitions and other attribute group definitions. The correspondences between theproperties of the information item andproperties of the component it corresponds to are as follows:

The example above illustrates a pattern whichrecurs in the XML representation of schemas: The same element, in this caseattributeGroup, serves both todefine and to incorporate by reference. In the first case thename attribute is required, in the second therefattribute is required, and the element must be empty. These two are mutually exclusive, and also conditionedby context: the defining form, with aname, must occur at the toplevel of a schema, whereas the referring form, with aref, mustoccur within a complex type definition or an attribute group definition.

3.6.3 Constraints on XML Representations of Attribute Group Definitions

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.

3.7.1 The Model Group Definition Schema Component

The model group definition schema component has the followingproperties:

Model group definitions are identified by their{name} and{target namespace}; model group identities must be unique within an·XML Schema·. SeeReferences to schema components across namespaces (§4.2.3) for the use of componentidentifiers when importing one schema into another.

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

{model group} is theModel Group (§2.2.3.1) for which the model group definition provides a name.

SeeAnnotations (§3.13) for information on the role of the{annotation} 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 andproperties of the component it corresponds to are as follows:

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 modelgroup 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 schemas does not allowthem on the child of<group> when it is named. This in turn isbecause the{min occurs} and{max occurs} ofthe particles whichrefer to the definition are what count.

Given the constraints on its appearance in content models, an<all> should only occur as the only item in the[children] of a named model group definition or a content model: seeConstraints on Model Group Schema Components (§3.8.6).

3.7.3 Constraints on XML Representations of Model Group Definitions

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.

3.8.1 The Model Group Schema Component

The model group schema component has the followingproperties:

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 group must:

• (sequence) correspond, in order, to the specified{particles};
• (choice) corresponded to exactly one of the specified{particles};
• (all) contain all and only exactly zero or one of eachelement specified in{particles}. The elements can occur in anyorder. In this case, to reduce implementation complexity,{particles} is restricted to contain local and top-level elementdeclarations only, with{min occurs}=0 or1,{max occurs}=1.

When two or more particles contained directly or indirectly in the{particles} of a model group have identically namedelement declarations as their{term}, the type definitions of those declarations must be thesame. By 'indirectly' is meant particles within the{particles}of a group which is itself the{term} of a directly containedparticle, and so on recursively.

SeeAnnotations (§3.13) for information on the role of the{annotation} 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 items andproperties of the component they correspond to are as follows:

3.8.3 Constraints on XML Representations of Model Groups

3.8.4 Model Group Validation Rules

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.

The following constraints define relations appealed to elsewhere in this specification.