Local element definitions

It is not necessary to define an element in one place, then refer to this definition in the content model of another element definition. When the element concerned is only used within the model of one other element, it is more efficient to simply define the sub-element in situ within the model of the outer element. The embedded element definition uses the Name attribute instead of the Ref attribute. Sub-elements of these inserted definitions can also be defined locally. In the following example, the Book element definition includes the Chapter element definition, and the Chapter element in turn defines the Paragraph element:

<element name="book">
  <!-- BOOK DEFINITION -->
  <complexType>
    <sequence>
      <element ref="DOC:title" />

      <!-- CHAPTER DEFINITION -->
      <element name="chapter" maxOccurs="unbounded">
        <complexType>
          <sequence>
            <element ref="DOC:title" />

            <!-- PARAGRAPH DEFINITION -->
            <element name="para" type="string" />

          </sequence>
        </complexType>
      </element>

    </sequence>
  </complexType>
</element>

Note that both the outer and inner models refer to the 'global' Title element definition. This demonstrates that it is possible to mix element definitions and element references.

Local limitations

The elements defined within the Book element above are known as 'local' elements because they have no existence beyond the location where they are defined. They cannot be referenced from other content models. Also, they can never be the root element of a conforming document (because there would be no context ancestor elements to unambiguously identify them).

Re-defining elements

Using local definitions, it is possible for the schema model to include several, context-specific element definitions that have the same name, but different content models or attributes. For example, within a Person element it may be desirable to have a Title element that is restricted to a few possible values, such as 'Mr', 'Mrs', 'Miss' and 'Ms'. A local definition overrides a global definition with the same name, and is also clearly distinct from any other definitions that are local to other element models:

<element name="title" type="string" />

<element name="chapter">
  <complexType>
    <sequence>
      <element name="title">...</element>
      ...
    </sequence>
  </complexType>
</element>

<element name="person">
  <complexType>
    <sequence>
      <element name="title">...</element>
      ...
    </sequence>
  </complexType>
</element>

Namespace prefix issues

This concept raises the issue that, within a compliant document, it is no longer sufficient to rely upon namespaces to specify exactly which element is being referenced. The context must also be taken into account. Apparently contrary to the Namespace specification, it is possible to specify in a schema that locally defined elements must be qualified (given a prefix, or assume the default namespace), or must not be qualified. This is a controversial concept, disparaged by many experts in the use of namespaces. It is particularly controversial because the latter option is the default mode. Consider the following example:

<listOfPeople>
  <title>This is a list of people</title>
  <P:person xmlns:P="...">
    <title>Mr</title>
    ...
  </P:person>
  ...
</listOfPeople>

In this example, the first Title element does not belong to any namespace. A namespace-sensitive parser will assume that the second title also does not belong to any namespace, because there is no default namespace declaration. The same problem would arise if the whole document belonged to a default namespace. Yet this title is defined within the same document model as the Person element containing it, so it really needs to be interpreted as belonging to the same namespace as the Person element. It should have the namespace prefix 'P:', and will therefore be misinterpreted by applications that are not schema-sensitive.

The other problem with this approach is that the document author needs to know which elements are forced to have a prefix, and which are forced to not have one (though a schema-sensitive XML editor could help considerably).

To overcome this issue, it is possible to specify that a prefix (or implied prefix, if the default namespace is in effect) must be present on local elements in the instance document. The ElementFormDefault attribute on the Schema element can be set to 'qualified' (from the default value of 'unqualified'). The example above would then need to be modified as shown below:

<listOfPeople>
  <title>This is a list of people</title>
  <P:person xmlns:P="...">
    <P:title>Mr</P:title>
    ...
  </P:person>
  ...
</listOfPeople>

The Form attribute on the Element element serves the same purpose, and has the same possible values, but specifies a setting for that element only (the Attribute element also has the Form attribute).