- Why Namespaces Are Needed: Resolving Name Conflicts
- Qualified Names, Prefixes, Local Names, and Other Terminology
- Declaring Namespaces in XML Documents
- Default Namespace
- Handling Namespaces in a DTD or XML Schema
- Validating Documents with Namespaces
- What Does a Namespace Point To?
- Namespace Support and Use
- Special Attributes: xmlns, xml:space, xml:lang, and xml:base
- Common Namespaces
- Summary
- For Further Exploration
This chapter is from the book
This chapter is from the book
This chapter is from the book
Namespace Support and Use
Due largely to the fact that XML namespaces post-date work on many XML specifications, they are treated differently by various XML technologies. Namespaces are treated simply as attributes by older technology like DTDs, DOM Level 1, and SAX1; they're treated as namespace declarations by XSLT, XPath, and XML Schema. However, with both DOM Level 2 and SAX2, they can be treated as either xmlns attributes or namespace declarations, depending on the context. XML Information Set, discussed later in this chapter, considers them Namespace Declaration Items.
The implication here is that tool support also varies and it is often necessary to enable namespace processing, especially with parsers. For example, when we cover SAX2, we'll see that by default namespaces are ignored, unless we enable them with something like this Java snippet:
saxParser.setFeature("http://xml.org/sax/features/namespaces",
true);
We'll also see that although DOM Level 1 is completely (and some might say, blissfully) ignorant of namespaces, DOM Level 2 is not. In addition to the older getAttribute, setAttribute, and getElementsByTagName methods, DOM Level 2 provides namespace-aware versions of these (and many others), all with names that end in "NS": getAttributeNS, setAttributeNS, and getElementsByTagNameNS.
Namespaces are an integral part of XSLT. In fact, you can't write an XSLT stylesheet without them because every element in XSLT requires a prefix so it can be easily differentiated from the elements of the language the stylesheet is processing or using in some other way. For example, in the following example, the xsl: prefix, which is associated with the namespace name http://www.w3.org/1999/XSL/ Transform, identifies the stylesheet's instructions (elements such as xsl:output, xsl:template, xsl:value-of, etc.) whereas the unprefixed elements are from HTML (html, head, title, body, h1, etc.).
<?xml version="1.0"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="html"/>
<xsl:template match="/">
<html>
<head>
<title>XSLT Example</title>
</head>
<body>
<h1>XSLT Example</h1>
<xsl:apply-templates select="//Book"/>
</body>
</html>
</xsl:template>
<xsl:template match="Book">
<br /><xsl:text>Book title: </xsl:text>
<i><xsl:value-of select="Title" /></i>
</xsl:template>
</xsl:stylesheet>
Namespace support can be found in some of the better XML editors that let you map a prefix to a URI, set default namespaces, and so on. Most of the more recent XML parsers also have methods for enabling namespace awareness. Therefore, in addition to nonvalidating and validating parsers, we now have namespace-aware validating parsers.