Namespaces in XML Schemas, Part 1: An Introduction

Print-friendly Version

[See also Part 2 of this series.]

A namespace defines a context in which identifiers must be unique. In an XML schema, you can create components, such as elements and types, which are named uniquely within the namespace of the schema. An element is the namespace's definition scope, which can override a namespace declaration defined in a parent element. Given that a namespace defines a context in which identifiers must be unique, schemas can safely integrate definitions from other namespaces—even those with the same names.

This article, part 1 of a series, explains a few nuances of XML and schema namespaces, along with examples. Part 2 will delve into more advanced details. NetBeans Enterprise Pack 5.5 delivers graphical editing and analysis capabilities for XML schemas. Nonetheless, a basic understanding of the ins and outs of namespaces in those schemas is essential.

With the xmlns attribute in an XML schema, you can define the following:

• A default namespace, which applies to elements with no prefixes.
  
  
• Prefixes that reference other namespaces. A prefix is an abbreviation for a namespace. To define a prefix, append a colon (:) and the prefix name to xmlns.

Consider this example:

<container xmlns="defaultURI" xmlns:ns1="prefixedURI">
        <ns1:child value="v"/>
</container>

Here, you can deduce the following:

• xmlns:nsl defines an ns1 prefix, an abbreviation for "prefixedURI".
  
  
• The default namespace for container is "defaultURI", which also applies to all the elements that do not override the default within container, such as child. In this example, child can also include a default namespace declaration that would override the namespace declaration from container within the context of child.
  
  This rule is similar to defining a local variable with the same name as a member variable in Java programming. When in scope, the local variable hides the global variable.
  
  
• The prefix, ns1 in this case, is an abbreviation for "prefixedURI". Thus, child is in the "prefixedURI" namespace. An alternative for achieving the same result is to define a default namespace, like this:
  
  <child xmlns="prefixedURI" value="v"/>

Note: No limit applies to the number of prefixes that can reference the same namespace, even within the same scope.

A schema declares a namespace with the targetNamespace attribute for the globally defined components. Those components are direct descendants of the schema element and the only ones that you can reference outside the schema. If you omit the targetNamespace attribute, the schema is defined as being without a namespace. You can specify whether elements and attributes are within targetNamespace with the elementFormDefault and attributeFormDefault attributes. The syntax looks like this:

<schema
    targetNamespace="xyz_namespace"
    elementFormDefault="qualified"
    attributeFormDefault="unqualified"
>

Note: Part 2 in this series will explain how to use other schemas—the import, include, and redefine elements—within a schema definition.

A common design is as follows:

• Define elementFormDefault as qualified so that all elements must be in a namespace in the conforming instance document.
  
  
• Leave attributeFormDefault as undefined, which defaults to unqualified, hence causing the attributes not to be in a namespace.

To override those values, define form for an attribute or element. For example, defining form as unqualified requires that the schema define all the attributes and elements within the same namespace. The default namespace in an instance document does not apply to attributes.

The following segment, which is derived from the po.xsd document distributed in the XML Schema Primer, illustrates the rules we just described.

1 <?xml version="1.0" encoding="UTF-8"?>
2
3 <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
4		 xmlns="http://www.w3.org/2001/XMLSchema/po.xsd"
5		 elementFormDefault="qualified"
6		 targetNamespace="http://www.w3.org/2001/XMLSchema/po.xsd">
7
8 <xsd:element name="purchaseOrder" type="PurchaseOrderType"/>
9
10 <xsd:element name="comment" type="xsd:string"/>
11
12 <xsd:complexType name="PurchaseOrderType">
13   <xsd:sequence>
14     <xsd:element name="shipTo" type="xsd:string"/>
15     <xsd:element name="billTo" type="xsd:string"/>
16     <xsd:element ref="comment" minOccurs="0"/>
17   </xsd:sequence>
18   <xsd:attribute name="orderDate" type="xsd:date"/>
19  </xsd:complexType>
20 </xsd:schema>

Here, you can deduce the following:

• The elements, purchaseOrder, comment, and complexType PurchaseOrderType, are defined in the "http://www.w3.org/2001/XMLSchema/po.xsd" namespace as a result of the definition for targetNamespace.
  
  
• The elementFormDefault attribute (line 5) requires that all elements be qualified. Toward that end, elements must use either prefixes or the default namespace.
  
  
• This schema does not define an attributeFormDefault attribute; thus, the default of unqualified is assumed.

See below for an example of a conforming instance document.

1 <?xml version="1.0" encoding="UTF-8"?>
2
3 <purchaseOrder xmlns='http://www.w3.org/2001/XMLSchema/po.xsd'
4 xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
5 xsi:schemaLocation='http://www.w3.org/2001/XMLSchema/po.xsd ./XMLNamespaceArticleSchema.xsd'
6                            orderDate="2005-11-05">
7     <shipTo>someAddress</shipTo>
8     <billTo>billingAddress</billTo>
9 </purchaseOrder>

Here, you can deduce the following:

• The root element, purchaseOrder, defines a default namespace of 'http://www.w3.org/2001/XMLSchema/po.xsd', which matches the target namespace of the po.xsd schema. That way, a schema validator can ensure that the instance document complies with the schema—that is, later on during validation, a validator will attempt to retrieve the schema definition that corresponds to this namespace.
  
  
• A namespace prefix xsi is declared and adopted for the prefix in the instance document (line 4).
  
  
• With the schemaLocation attribute, you can define a hint for a schema validator to access the schema definition (line 5). This is an example of a prefixed attribute. The value is a space-separated list that maps a namespace to a URI.
  
  
• The elements, purchaseOrder, billTo, and shipTo, belong to the default namespace because purchaseOrder defines a default namespace, which is not overridden by any of its children.
  
  
• The attribute orderDate (line 6) is not in a namespace because the default namespace does not apply to attributes.
  
  Note: Attributes cannot use the default namespace. If you define a prefix for the default namespace and prefix the orderDate attribute, a validation error occurs because orderDate is not in a namespace.

• XML Schema Part 0: Primer Second Edition
  
  
• Namespaces in XML
  
  
• NetBeans IDE
  • Main page
  • Net Talk programs
  
  
• NetBeans Enterprise Pack
  • Main page
  • Project page
  • Documentation
  • Technical articles
  • Video: XML Schema Tools
  • Article: Getting Started With XML Schema Tools
  • NetBeans XML Project
  
  
• Training
  • Java SE Platform
  • Java EE Platform
  
  
• Support

[See also Part 2 of this series.]