Table of contents

Appendices

3.3 Element Declarations

Element declarations provide for:

• Local valid of element information item values using a type definition;

• Specifying default or fixed values for an element information items;

• Establishing uniquenesses and reference constraint relationships among the values of related elements and attributes;

• Controlling the substitutability of elements through the mechanism of element substitution group.

NOTE: 

<xs:element name="PurchaseOrder" type="PurchaseOrderType"/>

<xs:element name="gift">
 <xs:complexType>
  <xs:sequence>
   <xs:element name="birthday" type="xs:date"/>
   <xs:element ref="PurchaseOrder"/>
  </xs:sequence>
 </xs:complexType>
</xs:element>

XML representations of several different types of element declaration

The Element Declaration Schema Component[top]

The element declaration schema component has the following properties:

The [e-name] property must match the local part of the names of element information items being valid.

A [e-scope] of global identifies element declarations available for use in content models throughout the schema. Locally scoped declarations are available for use only within the complex type identified by the [e-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 [e-target_namespace] property provides for valid of namespace-qualified element information items. absent values of [e-target_namespace] valid unqualified items.

An element information item is valid if it satisfies 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.

If [nillable] is true, then an element may also be valid if it carries the namespace qualified attribute with [local name] nil from namespace http://www.w3.org/2001/XMLSchema-instance and value true (see [xsi:nil]) even if it has no text or element content despite a [content_type] which would otherwise require content. Formal details of element valid are described in [Element Locally Valid (Element)].

[e-value_constraint] establishes a default or fixed value for an element. If default is specified, and if the element being valid is empty, then the canonical form of the supplied constraint value becomes the [e-schema_normalized_value] of the valid element in the post-schema-validation infoset. If fixed is specified, then the element's content must either be empty, in which case fixed behaves as default, or its value must match the supplied constraint value.

NOTE: 

The provision of defaults for elements goes beyond what is possible in XML 1.0 DTDs, and does not exactly correspond to defaults for attributes. In particular, an element with a non-empty [e-value_constraint] whose simple type definition includes the empty string in its lexical space will nonetheless never receive that value, because the [e-value_constraint] will override it.

[identity-constraint_definitions] express constraints establishing uniquenesses and reference relationships among the values of related elements and attributes. See [Identity-constraint Definitions].

Element declarations are members of the substitution group, if any, identified by [class_exemplar]. Membership is transitive but not symmetric; an element declaration is a member of any group of which its [class_exemplar] is a member.

An empty [e-final] allows a declaration to be nominated as the [class_exemplar] of other element declarations having the same [type_definition] or types derived therefrom. The explicit values of [e-final] rule out element declarations having types which are extensions or restrictions respectively of [type_definition]. If both values are specified, then the declaration may not be nominated as the [class_exemplar] of any other declaration.

The supplied values for [e-exact] determine whether an element declaration appearing in a content model will be prevented from additionally valid elements (a) with an [xsi:type] that identifies an extension or restriction of the type of the declared element, and/or (b) from valid elements which are in the substitution group headed by the declared element. If [e-exact] is empty, then all derived types and substitution group members are allowed.

Element declarations for which [e-abstract] is true can appear in content models only when substitution is allowed; such declarations may not themselves ever be used to valid element content.

See [Annotations] for information on the role of the [e-annotation] property.

XML Representation of Element Declaration Schema Components[top]

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, and may provide occurrence and default information. The correspondences between the properties of the information item and properties of the component(s) it corresponds to are as follows:

If the [element] element information item has [schema] as its parent, the corresponding schema component is as follows:

otherwise if the [element] element information item has [complexType] or [group] as an ancestor and the ref [attribute] is absent, the corresponding schema components are as follows (unless minOccurs=maxOccurs=0, in which case the item corresponds to no component at all):

An element declaration as in the first case above, with the exception of its [e-target_namespace] and [e-scope] properties, which are as below:

otherwise (the [element] element information item has [complexType] or [group] as an ancestor and the ref [attribute] is present), the corresponding schema component is as follows (unless minOccurs=maxOccurs=0, in which case the item corresponds to no component at all):

[element] corresponds to an element declaration, and allows the type definition of that declaration to be specified either by reference or by explicit inclusion.

[element]s within [schema] produce global element declarations; [element]s within [group] or [complexType] produce either particles which contain global element declarations (if there's a ref attribute) or local declarations (otherwise). For complete declarations, top-level or local, the type attribute is used when the declaration can use a built-in or pre-declared type definition. Otherwise an anonymous [simpleType] or [complexType] is provided inline.

Element information items valid by a top-level declaration must be qualified with the [e-target_namespace] of that declaration (if this is absent, the item must be unqualified). Control over whether element information items valid by a local declaration must be similarly qualified or not is provided by the form [attribute], whose default is provided by the elementFormDefault [attribute] on the enclosing [schema], via its determination of [e-target_namespace].

As noted above the names for top-level element declarations are in a separate symbol space from the symbol spaces for the names of type definitions, so there can (but need not be) a simple or complex type definition with the same name as a top-level element. As with attribute names, the names of locally-scoped element declarations with no [e-target_namespace] reside in symbol spaces local to the type definition which contains them.

Note that the above allows for two levels of defaulting for unspecified type definitions. An [element] with no referenced or included type definition will correspond to an element declaration which has the same type definition as the head 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 a name attribute and no contents, is also the most general, validating any combination of text and element content and allowing any attributes.

See below at [XML Representation of Identity-constraint Definition Schema Components] for [key], [unique] and [keyref].

NOTE: 

<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 the ur-type definition. The second uses an embedded anonymous complex type definition.

The last two examples illustrate the use of local element declarations. Instances of myLocalElement within contextOne will be constrained by myFirstType, while those within contextTwo will be constrained by mySecondType.

NOTE: 

The possibility that differing attribute declarations and/or content models would apply to elements with the same name in different contexts is an extension beyond the expressive power of a DTD in XML 1.0.

NOTE: 

 <xs:complexType name="facet">
  <xs:complexContent>
   <xs:extension base="xs:annotated">
    <xs:attribute name="value" use="required"/>
   </xs:extension>
  </xs:complexContent>
 </xs:complexType>

 <xs:element name="facet" type="xs:facet" abstract="true"/>

 <xs:element name="encoding" substitutionGroup="xs:facet">
  <xs:complexType>
   <xs:complexContent>
    <xs:restriction base="xs:facet">
     <xs:sequence>
      <xs:element ref="annotation" minOccurs="0"/>
     </xs:sequence>
     <xs:attribute name="value" type="xs:encodings"/>
    </xs:restriction>
   </xs:complexContent>
  </xs:complexType>
 </xs:element>

 <xs:element name="period" substitutionGroup="xs:facet">
  <xs:complexType>
   <xs:complexContent>
    <xs:restriction base="xs:facet">
     <xs:sequence>
      <xs:element ref="annotation" minOccurs="0"/>
     </xs:sequence>
     <xs:attribute name="value" type="xs:duration"/>
    </xs:restriction>
   </xs:complexContent>
  </xs:complexType>
 </xs:element>

 <xs:complexType name="datatype">
  <xs:sequence>
   <xs:element ref="facet" minOccurs="0" maxOccurs="unbounded"/>
  </xs:sequence>
  <xs:attribute name="name" type="xs:NCName" use="optional"/>
  . . .
 </xs:complexType>

An example from a previous version of the schema for datatypes. The facet type is defined and the facet element is declared to use it. The facet element is abstract -- it's only defined to stand as the head for a substitution group. Two further elements are declared, each a member of the facet substitution group. Finally a type is defined which refers to facet, thereby allowing either period or encoding (or any other member of the group).

Constraints on XML Representations of Element Declarations[top]

In addition to the conditions imposed on [element] element information items by the schema for schemas:

1. default and fixed must not both be present.

2. If the item's parent is not [schema], then

   1. One of ref or name must be present, but not both.

   2. If ref is present, then all of [complexType], [simpleType], [key], [keyref], [unique], nillable, default, fixed, form, block and type must be absent, i.e. only minOccurs, maxOccurs, id are allowed in addition to ref, along with [annotation].

3. type and either [simpleType] or [complexType] are mutually exclusive.

4. The corresponding particle and/or element declarations must satisfy the conditions set out in [Constraints on Element Declaration Schema Components] and [Constraints on Particle Schema Components].

Element Declaration Validation Rules[top]

For an element information item to be locally valid with respect to an element declaration

1. The declaration must not be absent.

2. Its [e-abstract] must be false.

3. 1. if[nillable] is false

      thenthere must be no attribute information item among the element information item's [attributes] whose [namespace name] is identical to http://www.w3.org/2001/XMLSchema-instance and whose [local name] is nil.

   2. if[nillable] is true and there is such an attribute information item and its actual value is true

      then

      1. The element information item must have no character or element information item [children].

      2. There must be no fixed [e-value_constraint].

4. If there is an attribute information item among the element information item's [attributes] whose [namespace name] is identical to http://www.w3.org/2001/XMLSchema-instance and whose [local name] is type, then

   1. The normalized value of that attribute information item must be valid with respect to the built-in QName simple type, as defined by [String Valid];

   2. The local name and namespace name (as defined in [QName Interpretation]), of the actual value of that attribute information item must resolve to a type definition, as defined in [QName resolution (Instance)] -- call this type definition the local type definition;

   3. The local type definition must be validly derived from the [type_definition] given the union of the [e-exact] and the [type_definition]'s [ct-exact], as defined in [Type Derivation OK (Complex)] (if it is a complex type definition), or given [e-exact] as defined in [Type Derivation OK (Simple)] (if it is a simple type definition).

   The phrase actual type definition occurs below. If the above three clauses are satisfied, this should be understood as referring to the local type definition, otherwise to the [type_definition].

5. 1. ifthe declaration has a [e-value_constraint], the item has neither element nor character [children] and [c-nl] has not applied

      then

      1. If the actual type definition is a local type definition then the canonical lexical representation of the [e-value_constraint] value must be a valid default for the actual type definition as defined in [Element Default Valid (Immediate)].

      2. The element information item with the canonical lexical representation of the [e-value_constraint] value used as its normalized value must be valid with respect to the actual type definition as defined by [Element Locally Valid (Type)].

   2. ifthe declaration has no [e-value_constraint] or the item has either element or character [children] or [c-nl] has applied

      then

      1. The element information item must be valid with respect to the actual type definition as defined by [Element Locally Valid (Type)].

      2. If there is a fixed [e-value_constraint] and [c-nl] has not applied,

         1. The element information item must have no element information item [children].

         2. 1. ifthe [content_type] of the actual type definition is mixed

               thenthe initial value of the item must match the canonical lexical representation of the [e-value_constraint] value.

            2. ifthe [content_type] of the actual type definition is a simple type definition

               thenthe actual value of the item must match the canonical lexical representation of the [e-value_constraint] value.

6. The element information item must be valid with respect to each of the [identity-constraint_definitions] as per [Identity-constraint Satisfied].

7. If the element information item is the validation root, it must be valid per [Validation Root Valid (ID/IDREF)].

For an element information item to be locally valid with respect to a type definition

1. The type definition must not be absent;

2. Its [ct-abstract] must be false.

3. 1. ifthe type definition is a simple type definition

      then

      1. The element information item's [attributes] must be empty, excepting those whose [namespace name] is identical to http://www.w3.org/2001/XMLSchema-instance and whose [local name] is one of type, nil, schemaLocation or noNamespaceSchemaLocation.

      2. The element information item must have no element information item [children].

      3. If [c-nl] of [Element Locally Valid (Element)] did not apply, then the normalized value must be valid with respect to the type definition as defined by [String Valid].

   2. ifthe type definition is a complex type definition

      thenthe element information item must be valid with respect to the type definition as per [Element Locally Valid (Complex Type)];

For an element information item which is the validation root to be valid

1. There must be no ID/IDREF binding in the item's [e-ii_table] whose [iib-binding] is the empty set.

2. There must be no ID/IDREF binding in the item's [e-ii_table] whose [iib-binding] has more than one member.

See [ID/IDREF Table] for the definition of ID/IDREF binding.

NOTE: 

The first clause above applies when there is a reference to an undefined ID. The second applies when there is a multiply-defined ID. They are separated out to ensure that distinct error codes (see [Outcome Tabulations (normative)]) are associated with these two cases.

NOTE: 

Although this rule applies at the validation root, in practice processors, particularly streaming processors, may wish to detect and signal the [c-uba] case as it arises.

NOTE: 

This reconstruction of [ref-xml]'s ID/IDREF functionality is imperfect in that if the validation root is not the document element of an XML document, the results will not necessarily be the same as those a validating parser would give were the document to have a DTD with equivalent declarations.

The schema-validity assessment of an element information item depends on its valid and the assessment of its element information item children and associated attribute information items, if any.

So for an element information item's schema-validity to be assessed

1. 1. 1. A non-absent element declaration must be known for it, because

         1. A declaration was stipulated by the processor (see [Assessing Schema-Validity]).

         2. A declaration has been established as its context-determined declaration.

         3. 1. Its context-determined declaration is not skip.

            2. Its [local name] and [namespace name] resolve to an element declaration as defined by [QName resolution (Instance)].

      2. Its valid with respect to that declaration must have been evaluated as per [Element Locally Valid (Element)].

      3. If that evaluation involved the evaluation of [Element Locally Valid (Type)], [c-ct] thereof must be satisfied.

   2. 1. A non-absent type definition is known for it because

         1. A type definition was stipulated by the processor (see [Assessing Schema-Validity]).

         2. 1. There is an attribute information item among the element information item's [attributes] whose [namespace name] is identical to http://www.w3.org/2001/XMLSchema-instance and whose [local name] is type.

            2. The normalized value of that attribute information item is valid with respect to the built-in QName simple type, as defined by [String Valid].

            3. The local name and namespace name (as defined in [QName Interpretation]), of the actual value of that attribute information item resolve to a type definition, as defined in [QName resolution (Instance)] -- call this type definition the local type definition.

            4. If there is also a processor-stipulated type definition, the item type definition must be validly derived from that type definition given its [ct-exact], as defined in [Type Derivation OK (Complex)] (if it is a complex type definition), or given the empty set, as defined in [Type Derivation OK (Simple)] (if it is a simple type definition).

      2. The element information item's valid with respect to the item type definition (if present and validly derived) or the processor-stipulated type definition (if no item type definition is present) has been evaluated as per [Element Locally Valid (Type)].

2. The schema-validity of all the element information items among its [children] has been assessed as per [Schema-Validity Assessment (Element)], and the schema-validity of all the attribute information items among its [attributes] has been assessed as per [Schema-Validity Assessment (Attribute)].

If either case of [c-xd] above holds, the element information item has been strictly assessed.

If the item cannot be strictly assessed, because neither [c-ed] nor [c-td] above are satisfied, an element information item's schema validity may be laxly assessed if its context-determined declaration is not skip by valid with respect to the Complex Type Definition of the Ur-Type as per [Element Locally Valid (Type)].

NOTE: 

In general if [c-ed] above holds [c-td] does not, and vice versa. When an xsi:type [attribute] is involved, however, [c-td] takes precedence, as is made clear in [Element Locally Valid (Element)].

NOTE: 

The [e-name] and [e-target_namespace] properties are not mentioned above because they are checked during particle valid, as per [Element Sequence Locally Valid (Particle)].

Element Declaration Information Set Contributions[top]

If the schema-validity of an element information item has been assessed as per [Schema-Validity Assessment (Element)], then in the post-schema-validation infoset it has properties as follows:

1. ifit was strictly assessed

   then

   1. if

      1. 1. [c-ed] of [Schema-Validity Assessment (Element)] applied and the item was valid as defined by [Element Locally Valid (Element)];

         2. [c-td] of [Schema-Validity Assessment (Element)] applied and the item was valid as defined by [Element Locally Valid (Type)].

      2. Neither its [children] nor its [attributes] contains an information item (element or attribute respectively) whose [validity] is invalid.

      3. Neither its [children] nor its [attributes] contains an information item (element or attribute respectively) with a context-determined declaration of mustFind whose [validity] is unknown.

      thenvalid;

   2. otherwiseinvalid..

2. otherwisenotKnown.

1. ifit was strictly assessed and neither its [children] nor its [attributes] contains an information item (element or attribute respectively) whose [validation attempted] is not full

   thenfull;

2. ifit was not strictly assessed and neither its [children] nor its [attributes] contains an information item (element or attribute respectively) whose [validation attempted] is not none

   thennone;

3. otherwisepartial.

If the local valid, as defined by [Element Locally Valid (Element)] above and/or [Element Locally Valid (Type)] below, of an element information item has been assessed, in the post-schema-validation infoset the item has a property:

1. ifthe item is not valid

   thena list. Applications wishing to provide information as to the reason(s) for the valid failure are encouraged to record one or more error codes (see [Outcome Tabulations (normative)]) herein.

2. otherwiseabsent.

If an element information item is valid with respect to an element declaration as per [Element Locally Valid (Element)] then in the post-schema-validation infoset the element information item must, at processor option, have either:

or

If an element information item is valid with respect to a type definition as per [Element Locally Valid (Type)], in the post-schema-validation infoset the item has a property:

1. if[c-nl] of [Element Locally Valid (Element)] and [Element Default Value] above have not applied and either the type definition is a simple type definition or its [content_type] is a simple type definition

   then the normalized value of the item as valid.

2. otherwiseabsent.

Furthermore, the item has one of the following alternative sets of properties:

Either

or

If the type definition is a simple type definition or its [content_type] is a simple type definition, and that type definition has [variety] union, then calling that member of the [st-member_type_definitions] which actually valid the element item's normalized value the actual member type definition, there are three additional properties:

The first (item isomorphic to a component) alternative above is provided for applications such as query processors which need access to the full range of details about an item's assessment, for example the type hierarchy; the second, for lighter-weight processors for whom representing the significant parts of the type hierarchy as information items might be a significant burden.

Also, if the declaration has a [e-value_constraint], the item has a property:

Note that if an element is laxly assessed, then the [e-type_definition] and [e-member_type_definition] properties, or their alternatives, are based on the Complex Type Definition of the Ur-Type.

If the local valid, as defined by [Element Locally Valid (Element)] above, of an element information item has been assessed, in the post-schema-validation infoset the item has a property:

1. ifthe item is valid with respect to an element declaration as per [Element Locally Valid (Element)] and the [e-value_constraint] is present, but [c-nl] of [Element Locally Valid (Element)] above is not satisfied and the item has no element or character information item [children]

   then schema. Furthermore, the post-schema-validation infoset has the canonical lexical representation of the [e-value_constraint] value as the item's [e-schema_normalized_value] property.

2. otherwiseinfoset.

Constraints on Element Declaration Schema Components[top]

All element declarations (see [Element Declarations]) must satisfy the following constraint.

1. The values of the properties of an element declaration must be as described in the property tableau in [The Element Declaration Schema Component], modulo the impact of [Missing Sub-components].

2. If there is a [e-value_constraint], the canonical lexical representation of its value must be valid with respect to the [type_definition] as defined in [Element Default Valid (Immediate)].

3. If there is an [class_exemplar], the [type_definition] of the element declaration must be validly derived from the [type_definition] of the [class_exemplar], given the value of the [e-final] of the [class_exemplar], as defined in [Type Derivation OK (Complex)] (if the [type_definition] is complex) or as defined in [Type Derivation OK (Simple)] (if the [type_definition] is simple).

4. If the [type_definition] or [type_definition]'s [content_type] is or is derived from ID then there must not be a [e-value_constraint].

   NOTE: 

   The use of ID as a type definition for elements goes beyond XML 1.0, and should be avoided if backwards compatibility is desired.

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

For a string to be a valid default with respect to a type definition

1. ifthe type definition is a simple type definition

   thenthe string must be valid with respect to that definition as defined by [String Valid].

2. ifthe type definition is a complex type definition

   then

   1. its [content_type] must be a simple type definition or mixed.

   2. 1. ifthe [content_type] is a simple type definition

         thenthe string must be valid with respect to that simple type definition as defined by [String Valid].

      2. ifthe [content_type] is mixed

         thenthe [content_type]'s particle must be emptiable as defined by [Particle Emptiable].

For an element declaration (call it D) together with a blocking constraint (a subset of {substitution, extension, restriction}, the value of a [e-exact]) to be validly substitutable for another element declaration (call it C)

1. The blocking constraint does not contain substitution.

2. There is a chain of [class_exemplar]s from D to C, that is, either D's [class_exemplar] is C, or D's [class_exemplar]'s [class_exemplar] is C, or . . .

3. The set of all [derivation_method]s involved in the derivation of D's [type_definition] from C's [type_definition] does not intersect with the union of the blocking constraint, C's [ct-exact] (if C is complex, otherwise the empty set) and the [ct-exact] (respectively the empty set) of any intermediate [type_definition]s in the derivation of D's [type_definition] from C's [type_definition].

Every element declaration in the [element_declarations] of a schema defines a substitution group, a subset of those [element_declarations], as follows:

1. The element declaration itself is in the group;

2. The group is closed with respect to [class_exemplar], that is, if any element declaration in the [element_declarations] has a [class_exemplar] in the group, then it is also in the group itself.