Namespace Declarations (XML Schema)

start page | rating of books | rating of authors | reviews | copyrights

10.2. Namespace Declarations

Until now, we have seen schemas for documents that had no namespace declarations of any kind and, therefore, did not belong to any namespace. To match the documents without namespaces, the schemas had no namespace declaration either, except the one needed to identify the W3C XML Schema namespace itself.

To match the elements and attributes that belong to a namespace, we need to associate this namespace with our schema through the targetNamespace attribute of the xs:schema element.

If we modify our library to use a single namespace:

<library xmlns="http://dyomedea.com/ns/library">
  <book id="b0836217462" available="yes">
    <isbn>
      0836217462
    </isbn>
    <title>
      Being a Dog Is a Full-Time Job
    </title>
    .../...
  </book>
</library>

We need to modify our schema to declare the namespace and to define it as the target namespace:

<xs:schema targetNamespace="http://dyomedea.com/ns/library"
  elementFormDefault="qualified" attributeFormDefault="unqualified"
  xmlns:lib="http://dyomedea.com/ns/library"
  xmlns:xs="http://www.w3.org/2001/XMLSchema">
  .../...
</xs:schema>

The definition of the namespaces is especially important here, since W3C XML Schema uses them for two purposes.

As for any XML document that conforms to the namespaces Recommendation, the first purpose of the namespace declaration is to associate a URI reference that is the identifier of a namespace to a prefix, which is a shortcut for this identifier.

In our example, we have two such declarations: xmlns:xs="http://www.w3.org/2001/XMLSchema" and xmlns:lib="http://dyomedea.com/ns/library".

The first declaration associates the W3C XML Schema namespace with the prefix xs. We could, of course, have chosen any prefix, or even used this namespace as the default namespace; the choice of xs is just common usage.

The second declaration defines the namespace used in our instance document, xmlns:lib="http://dyomedea.com/ns/library". Here we chose to use the lib prefix, even though this namespace is never used for any element or attribute of the schema itself. We could also have chosen any prefix for this namespace, or even have defined it as our default namespace.

This second declaration is needed for the second usage of namespace prefixes. W3C XML Schema uses the namespace prefixes to resolve all the references to the components of a schema (datatypes, elements, attributes, groups, etc.), as well as for the XPath expressions used in the xs:unique, xs:key, and xs:keyref declarations.

We haven't yet mentioned which namespace this schema describes. We must do so using the targetNamespace attribute that defines the URI reference that identifies the target namespace.

With this last piece of information, a schema processor knows what the target namespace is. With the two namespaces declarations already complete, it also knows which prefix we want to use for it and for the W3C XML Schema namespace. This is sufficient information to write our schema.

NOTE: This use of the namespace prefixes, common to W3C XML Schema and XSLT, is very controversial, since it creates a dependency between W3C XML Schema (considered an application) and the prefixes chosen for the namespaces. This breaks the layered structure of the XML specifications: the markup and its content become interdependent and cannot be changed independently any longer.

Not unlike a communication protocol, the XML specifications may be seen as a set of envelopes. XML 1.0 is the outermost envelope into which the namespaces are included. While the applications should be independent of these envelopes, the fact that W3C XML Schema is making use of the namespace prefixes inside its own attributes glues the schema to its envelope. This is a very dangerous practice that should be discouraged for other vocabularies that define their own sets of prefixes.

One of the consequences of this practice is that Canonical XML has been obliged to remove namespace prefix rewriting from its requirements, meaning that the four flavors of our library that are strictly equivalent, per the namespace recommendation, will have four different canonical values, and different digital signatures as a result.


10. Controlling Namespaces		10.3. To Qualify Or Not to Qualify?