Databases Reference
In-Depth Information
Namespace considerations
Namespaces are one of the biggest areas of confusion with XML Schemas, yet
in reality, they are very straightforward. The purpose of a namespace is just to
provide a unique name for an element, type, or attribute, thus allowing us to
define components with the same name.
For example, the element
Glass
, will have a different definition to a company
that sells windows as opposed to one that runs a bar. The namespace allows us to
uniquely identify each definition, so that we can use both definitions within the
same instance of an XML document, as well as understand the context in which
each element is being used.
If you're familiar with Java, then a namespace is a bit like a package
name, that is, you can have multiple classes with the same name,
but each one would be defined in a separate package.
One feature of namespaces is that they have a degree of flexibility in how you
apply them, which then impacts how you construct and interpret an instance of an
XML document. This is often a cause of confusion, especially when they are used
inconsistently across multiple schemas.
So it's critical that you define a standard approach to namespaces before defining
your canonical model.
Always specify a target namespace
Unless you are defining a chameleon schema (seen later in the chapter) always
specify a target namespace.
Default namespace
When defining a schema, you have the option of defining a default namespace. If
you do, we would recommend setting the default namespace to be equal to the target
namespace. The advantage of this approach is that you only prefix elements, types,
and attributes that are defined externally to the schema (that is, anything that is not
prefixed is defined locally).
An alternative approach is not to use a default namespace, so that all
elements require a prefix. This can often be clearer when combining many
schemas from multiple namespaces, especially if you have similarly
named elements.
