Beginning Microsoft SQL Server 2008 ... - S3 Tech Training

Chapter 16: A Brief XML Primer
Namespaces
484
With all this freedom to create your own tags, to mix and match data from other sources, and just otherwise
do your own thing, there are bound to be a few collisions here and there about what things are going
to use what names in which places. For example, an element with a name of “letter” might have entirely
different structure, rules, and meaning to an application built for libraries (for whom a letter is probably a
document written from one person to another person) than it would to another application, say one
describing fonts (which might describe the association between a character set and a series of glyphs).
To take this example a little further, the nature of XML is such that industry organizations around the
world are slowly agreeing on naming and structure conventions to describe various types of information
in their industry. Library organizations may have agreed on element formats describing books, plays,
movies, letters, essays, and so on. At the same time, the operating systems and/or graphics industries
may have agreed on element formats describing pictures, fonts, and document layouts.
Now, imagine that we, the poor hapless developers that we are, have been asked to write an application
that needs to render library content. Obviously, library content makes frequent use of things like fonts —
so, when you refer to something called “letter” in your XML, are you referring to something to do with
the font or is it a letter from a person to another person (say, from Thomas Jefferson to George Washington)?
We have a conflict, and we need a way to resolve it.
That’s where namespaces come in. Namespaces describe a domain of elements and attributes and what
their structure is. The structure that supports letters in libraries would be described in a libraries namespace.
Likewise, the graphics industry would likely have their own namespace(s) that would describe
letters as they relate to that industry. The information for a namespace is stored in a reference document,
and can be found using a Uniform Resource Identifier (URI) — a special name, not dissimilar from a
URL — that will eventually resolve to our reference document.
When we build our XML documents that refer to both library and graphics constructs, then we simply
reference the namespaces for those industries. In addition, we qualify elements and attributes whose
nature we want the namespace to describe. By qualifying our names using namespaces, we make sure
that, even if a document has elements that are structurally different but have the same name, we can
refer to the parts of our document with complete confidence that we are not referring to the wrong kind
of element or attribute.
To reference a namespace to the entire document, we simply add the reference as a special attribute
(called xmlns) to our root. The reference will provide both a local name (how we want to refer to the
namespace) and the URI that will eventually resolve to our reference document. We can also add namespace
references (again, using xmlns) to other nodes in the document if we want to apply only that particular
namespace within the scope of the node we assign the namespace, too.
What follows is an example of an XML document (technically, this is what we call a schema) that we will
be utilizing later in the chapter. Notice several things about it as relates to namespaces:
The document references three namespaces — one each for XDR (this happens to be an XDR document),
a Microsoft data type namespace (this one builds a list about the number and nature of different data types),
and, last, but not least, a special SQL namespace used for working with SQL Server XML integration.
Some attributes (including one in the root) are qualified with namespace information (see the
sql:relation attribute, for example).