Table of contents

Appendices

5.4 Importing Types

ref41The report schema, report.xsd, makes use of the simple type xipo:SKU that is defined in another schema, and in another target namespace. Recall that we used include so that the schema in ipo.xsd could make use of definitions and declarations from address.xsd. We cannot use include here because it can only pull in definitions and declarations from a schema whose target namespace is the same as the including schema's target namespace. Hence, the include element does not identify a namespace (although it does require a schemaLocation). The import mechanism that we describe in this section is an important mechanism that enables schema components from different target namespaces to be used together, and hence enables the schema validation of instance content defined across multiple namespaces.

ref31To import the type SKU and use it in the report schema, we identify the namespace in which SKU is defined, and associate that namespace with a prefix for use in the report schema. Concretely, we use the import element to identify SKU's target namespace, http://www.example.com/IPO, and we associate the namespace with the prefix xipo using a standard namespace declaration. The simple type SKU, defined in the namespace http://www.example.com/IPO, may then be referenced as xipo:SKU in any of the report schema's definitions and declarations.

In our example, we imported one simple type from one external namespace, and used it for declaring attributes. XML Schema in fact permits multiple schema components to be imported, from multiple namespaces, and they can be referred to in both definitions and declarations. For example in report.xsd we could additionally reuse the comment element declared in ipo.xsd by referencing that element in a declaration:

NOTE: 

<element ref="xipo:comment"/>

Note however, that we cannot reuse the shipTo element from delpo.xsdaddipo.xsd, and the following is not legal because only global schema components can be imported:

NOTE: 

<element ref="xipo:shipTo"/>

In ipo.xsd, comment is declared as a global element, in other words it is declared as an element of the schema. In contrast, shipTo is declared locally, in other words it is an element declared inside a complex type definition, specifically the PurchaseOrderType type.

Complex types can also be imported, and they can be used as the base types for deriving new types. Only named complex types can be imported; local, anonymously defined types cannot. Suppose we want to include in our reports the name of an analyst, along with contact information. We can reuse the (globally defined) complex type USAddress from address.xsd, and extend it to define a new type called Analyst in the report schema by adding the new elements phone and email:

NOTE: 

Defining Analyst by Extending USAddress

<complexType name="Analyst">
 <complexContent>
  <extension base="xipo:USAddress">
   <sequence>
    <element name="phone" type="string"/>
    <element name="email" type="string"/>
   </sequence>
  </extension>
 </complexContent>
</complexType>

Using this new type we declare an element called analyst as part of the purchaseReport element declaration (declarations not shown) in the report schema. Then, the following instance document would conform to the modified report schema:

NOTE: 

Instance Document Conforming to Report Schema with Analyst Type

<r:purchaseReport
  xmlns:r="http://www.example.com/Report"
  period="P3M" periodEnding="1999-12-31">
  <!-- regions and parts elements omitted -->
   <r:analyst>
        <name>Wendy Uhro</name>
        <street>10 Corporate Towers</street>
        <city>San Jose</city>
        <state>CA</state>
        <zip>95113</zip>
        <r:phone>408-271-3366</r:phone>
        <r:email>uhro@example.com</r:email>
   </r:analyst>
</r:purchaseReport>

add Note that the report now has both qualified and unqualified elements. This is because some of the elements (name, street, city, state and zip) are locally declared in ipo.xsd, whose elementFormDefault is unqualified (by default). The other elements in the example are declared in report.xsd, whose elementFormDefault is set to qualified.

When schema components are imported from multiple namespaces, each namespace must be identified with a separate import element. The import elements themselves must appear as the first children of the schema element. Furthermore, each namespace must be associated with a prefix, using a standard namespace declaration, and that prefix is used to qualify references to any schema components belonging to that namespace. Finally, import elements optionally contain a schemaLocation attribute to help locate resources associated with the namespaces. We discuss the schemaLocation attribute in more detail in a later section.

Type Libraries[top]

As XML schemas become more widespread, schema authors will want to create simple and complex types that can be shared and used as building blocks for creating new schemas. XML Schemas already provides types that play this role, in particular, the types described in the Simple Types appendix and in an introductory type library.

Schema authors will undoubtedly want to create their own libraries of types to represent currency, units of measurement, business addresses, and so on. Each library might consist of a schema containing one or more definitions, for example, a schema containing a currency type:

NOTE: 

Example Currency Type in Type Library

<schema targetNamespace="http://www.example.com/Currency"
        xmlns:c="http://www.example.com/Currency"
        xmlns="http://www.w3.org/2001/XMLSchema">

  <annotation>
    <documentation xml:lang="en">
      Definition of Currency type based on ISO 4217
    </documentation>
  </annotation>

  <complexType name="Currency">
    <simpleContent>
      <extension base="decimal">
        <attribute name="name">
          <simpleType>
            <restriction base="string">

              <enumeration value="AED">
                <annotation>
                  <documentation xml:lang="en">
                    United Arab Emirates: Dirham (1 Dirham = 100 Fils)
                  </documentation>
                </annotation>
              </enumeration>

              <enumeration value="AFA">
                <annotation>
                  <documentation xml:lang="en">
                    Afghanistan: Afghani (1 Afghani = 100 Puls)
                  </documentation>
                </annotation>
              </enumeration>

              <enumeration value="ALL">
                <annotation>
                  <documentation xml:lang="en">
                    Albania, Lek (1 Lek = 100 Qindarka)
                  </documentation>
                </annotation>
              </enumeration>

              <!-- and other currencies -->

            </restriction>
          </simpleType>
        </attribute>
      </extension>
    </simpleContent>
  </complexType>

</schema>

An example of an element appearing in an instance and having this type:

NOTE: 

<convertFrom name="AFA">199.37</convertFrom>

Once we have defined the currency type, we can make it available for re-use in other schemas through the import mechanism just described.