Table of contents

Appendices

3.1 Target Namespaces & Unqualified Locals

ref56 In a new version of the purchase order schema, po1.xsd, we explicitly declare a target namespace, and specify that both locally defined elements and locally defined attributes must be unqualified. The target namespace in po1.xsd is http://www.example.com/PO1, as indicated by the value of the targetNamespace attribute.

ref50Qualification of local elements and attributes can be globally specified by a pair of attributes, elementFormDefault and attributeFormDefault, on the schema element, or can be specified separately for each local declaration using the form attribute. All such attributes' values may each be set to unqualified or qualified, to indicate whether or not locally declared elements and attributes must be unqualified.

In po1.xsd we globally specify the qualification of elements and attributes by setting the values of both elementFormDefault and attributeFormDefault to unqualified. Strictly speaking, these settings are unnecessary because the values are the defaults for the two attributes; we make them here to highlight the contrast between this case and other cases we describe later.

NOTE: 

Purchase Order Schema with Target Namespace, po1.xsd

<schema xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:po="http://www.example.com/PO1"
        targetNamespace="http://www.example.com/PO1"
        elementFormDefault="unqualified"
        attributeFormDefault="unqualified">

  <element name="purchaseOrder" type="po:PurchaseOrderType"/>
  <element name="comment"       type="string"/>

  <complexType name="PurchaseOrderType">
    <sequence>
      <element name="shipTo"    type="po:USAddress"/>
      <element name="billTo"    type="po:USAddress"/>
      <element ref="po:comment" minOccurs="0"/>
      <!-- etc. -->
    </sequence>
    <!-- etc. -->
  </complexType>

  <complexType name="USAddress">
    <sequence>
      <element name="name"   type="string"/>
      <element name="street" type="string"/>
      <!-- etc. -->
    </sequence>
  </complexType>

  <!-- etc. -->

</schema>

To see how the target namespace of this schema is populated, we examine in turn each of the type definitions and element declarations. Starting from the end of the schema, we first define a type called USAddress that consists of the elements name, street, etc. One consequence of this type definition is that the USAddress type is included in the schema's target namespace. We next define a type called PurchaseOrderType that consists of the elements shipTo, billTo, comment, etc. PurchaseOrderType is also included in the schema's target namespace. Notice that the type references in the three element declarations are prefixed, i.e. po:USAddress, po:USAddress and po:comment, and the prefix is associated with the namespace http://www.example.com/PO1. This is the same namespace as the schema's target namespace, and so a processor of this schema will know to look within this schema for the definition of the type USAddress and the declaration of the element comment. It is also possible to refer to types in another schema with a different target namespace, hence enabling re-use of definitions and declarations between schemas.

At the beginning of the schema po1.xsd, we declare the elements purchaseOrder and comment. They are included in the schema's target namespace. The purchaseOrder element's type is prefixed, for the same reason that USAddress is prefixed. In contrast, the comment element's type, string, is not prefixed. The po1.xsd schema contains a default namespace declaration, and so unprefixed types such as string and unprefixed elements such as element and complexType are associated with the default namespace http://www.w3.org/2001/XMLSchema. In fact, this is the target namespace of XML Schema itself, and so a processor of po1.xsd will know to look within the schema of XML Schema -- otherwise known as the "schema for schemas" -- for the definition of the type string and the declaration of the element called element.

Let us now examine how the target namespace of the schema affects a conforming instance document:

NOTE: 

A Purchase Order with Unqualified Locals, po1.xml

<?xml version="1.0"?>
<apo:purchaseOrder xmlns:apo="http://www.example.com/PO1"
                   orderDate="1999-10-20">
  <shipTo country="US">
    <name>Alice Smith</name>
    <street>123 Maple Street</street>
    <!-- etc. -->
  </shipTo>
  <billTo country="US">
    <name>Robert Smith</name>
    <street>8 Oak Avenue</street>
    <!-- etc. -->
  </billTo>
  <apo:comment>Hurry, my lawn is going wild<!/apo:comment>
  <!-- etc. -->
</apo:purchaseOrder>

The instance document declares one namespace, http://www.example.com/PO1, and associates it with the prefix apo:. This prefix is used to qualify two elements in the document, namely purchaseOrder and comment. The namespace is the same as the target namespace of the schema in po1.xsd, and so a processor of the instance document will know to look in that schema for the declarations of purchaseOrder and comment. In fact, target namespaces are so named because of the sense in which there exists a target namespace for the elements purchaseOrder and comment. Target namespaces in the schema therefore control the validation of corresponding namespaces in the instance.

The prefix apo: is applied to the global elements purchaseOrder and comment elements. Furthermore, elementFormDefault and attributeFormDefault require that the prefix is not applied to any of the locally declared elements such as shipTo, billTo, name and street, and it is not applied to any of the attributes (which were all declared locally). The purchaseOrder and comment are global elements because they are declared in the context of the schema as a whole rather than within the context of a particular type. For example, the declaration of purchaseOrder appears as a child of the schema element in po1.xsd, whereas the declaration of shipTo appears as a child of the complexType element that defines PurchaseOrderType.

When local elements and attributes are not required to be qualified, an instance author may require more or less knowledge about the details of the schema to create schema valid instance documents. More specifically, if the author can be sure that only the root element (such as purchaseOrder) is global, then it is a simple matter to qualify only the root element. Alternatively, the author may know that all the elements are declared globally, and so all the elements in the instance document can be prefixed, perhaps taking advantage of a default namespace declaration. (We examine this approach in [Global vs. Local Declarations].) On the other hand, if there is no uniform pattern of global and local declarations, the author will need detailed knowledge of the schema to correctly prefix global elements and attributes.