PART II: DECLARING AND USING XML NAMESPACES
4) SECTION 4: DECLARING XML NAMESPACES IN AN XML DOCUMENT
4.1) How do I declare an XML namespace in an XML document?
To declare an XML namespace, you use an attribute whose name has the form:
xmlns:prefix
--OR--
xmlns
These attributes are often called xmlns attributes and their value is the name of the XML namespace being declared; this is a URI. The first form of the attribute (xmlns:prefix) declares a prefix to be associated with the XML namespace. The second form (xmlns) declares that the specified namespace is the default XML namespace.
For example, the following declares two XML namespaces, named http://www.tu-darmstadt.de/ito/addresses and http://www.tu-darmstadt.de/ito/servers. The first declaration associates the addr prefix with the http://www.tu-darmstadt.de/ito/addresses namespace and the second declaration states that the http://www.tu-darmstadt.de/ito/servers namespace is the default XML namespace.
<Department
xmlns:addr="http://www.tu-darmstadt.de/ito/addresses"
xmlns="http://www.tu-darmstadt.de/ito/servers">
NOTE: Technically, xmlns attributes are not attributes at all -- they are XML namespace declarations that just happen to look like attributes. Unfortunately, they are not treated consistently by the various XML recommendations, which means that you must be careful when writing an XML application.
For example, in the XML Information Set (http://www.w3.org/TR/xml-infoset), xmlns "attributes" do not appear as attribute information items. Instead, they appear as namespace declaration information items. On the other hand, both DOM level 2 and SAX 2.0 treat namespace attributes somewhat ambiguously. In SAX 2.0, an application can instruct the parser to return xmlns "attributes" along with other attributes, or omit them from the list of attributes. Similarly, while DOM level 2 sets namespace information based on xmlns "attributes", it also forces applications to manually add namespace declarations using the same mechanism the application would use to set any other attributes.
4.2) Where can I declare an XML namespace?
You can declare an XML namespace on any element in an XML document. The namespace is in scope for that element and all its descendants unless it is overridden (see question 4.5 and question 4.6) or undeclared (see question 4.8). For more information about scope, see section 6.
4.3) Can I use an attribute default in a DTD to declare an XML namespace?
Yes.
For example, the following uses the FIXED attribute xmlns:foo on the A element type to associate the foo prefix with the http://www.foo.org/ namespace. The effect of this is that both A and B are in the http://www.foo.org/ namespace.
<?xml version="1.0" ?>
<!DOCTYPE foo:A [
<!ELEMENT foo:A (foo:B)>
<!ATTLIST foo:A
xmlns:foo CDATA #FIXED "http://www.foo.org/">
<!ELEMENT foo:B (#PCDATA)>
]>
<!-- foo prefix declared through default attribute. -->
<foo:A>
<foo:B>abc</foo:B>
</foo:A>
IMPORTANT: You should be very careful about placing XML namespace declarations in external entities (external DTDs), as non-validating parsers are not required to read these. For example, suppose the preceding DTD was placed in an external entity (foo.dtd) and that the document was processed by a non-validating parser that did not read foo.dtd. This would result in a namespace error because the foo prefix was never declared:
<?xml version="1.0" ?>
<!-- foo.dtd might not be read by non-validating parsers. -->
<!DOCTYPE foo:A SYSTEM "foo.dtd">
<!-- foo prefix not declared unless foo.dtd is read. -->
<foo:A>
<foo:B>abc</foo:B>
</foo:A>
4.4) Do the default values of xmlns attributes declared in the DTD apply to the DTD?
No.
Declaring a default value of an xmlns attribute in the DTD does not declare an XML namespace for the DTD. (In fact, no XML namespace declarations apply to DTDs.) Instead, these defaults (declarations) take effect only when the attribute is instantiated on an element. For example:
<?xml version="1.0" ?>
<!DOCTYPE foo:A [
<!ELEMENT foo:A (foo:B)>
<!ATTLIST foo:A
xmlns:foo CDATA #FIXED "http://www.foo.org/">
<!ELEMENT foo:B (#PCDATA)>
]>
<foo:A> <========== Namespace declaration takes effect here.
<foo:B>abc</foo:B>
</foo:A> <========= Namespace declaration ends here.
For more information, see question 7.2. (Note that an earlier version of MSXML (the parser used by Internet Explorer) did use fixed xmlns attribute declarations as XML namespace declarations, but that this was removed in MSXML 4. For more information, see question 8.6.)
4.5) How do I override an XML namespace declaration that uses a prefix?
To override the prefix used in an XML namespace declaration, you simply declare another XML namespace with the same prefix. For example, in the following, the foo prefix is associated with the http://www.foo.org/ namespace on the A and B elements and the http://www.bar.org/ namespace on the C and D elements. That is, the names A and B are in the http://www.foo.org/ namespace and the names C and D are in the http://www.bar.org/ namespace.
<foo:A xmlns:foo="http://www.foo.org/">
<foo:B>
<foo:C xmlns:foo="http://www.bar.org/">
<foo:D>abcd</foo:D>
</foo:C>
</foo:B>
</foo:A>
In general, this leads to documents that are confusing to read and should be avoided.
4.6) How do I override a default XML namespace declaration?
To override the current default XML namespace, you simply declare another XML namespace as the default. For example, in the following, the default XML namespace is the http://www.foo.org/ namespace on the A and B elements and the http://www.bar.org/ namespace on the C and D elements. That is, the names A and B are in the http://www.foo.org/ namespace and the names C and D are in the http://www.bar.org/ namespace.
<A xmlns="http://www.foo.org/">
<B>
<C xmlns="http://www.bar.org/">
<D>abcd</D>
</C>
</B>
</A>
Using multiple default XML namespaces can lead to documents that are confusing to read and should be done carefully. For more information, see question 5.4.
4.7) How do I undeclare an XML namespace prefix?
In version 1.0 of the XML namespaces recommendation, you cannot "undeclare" an XML namespace prefix. It remains in scope until the end of the element on which it was declared unless it is overridden. Furthermore, trying to undeclare a prefix by redeclaring it with an empty (zero-length) name (URI) results in a namespace error. For example:
<foo:A xmlns:foo="http://www.foo.org/">
<foo:B>
<foo:C xmlns:foo=""> <==== This is an error in v1.0, legal in v1.1.
<foo:D>abcd</foo:D>
</foo:C>
</foo:B>
</foo:A>
In version 1.1 of the XML namespaces recommendation [currently a candidate recommendation -- February, 2003], you can undeclare an XML namespace prefix by redeclaring it with an empty name. For example, in the above document, the XML namespace declaration xmlns:foo="" is legal and removes the mapping from the foo prefix to the http://www.foo.org URI. Because of this, the use of the foo prefix in the foo:D element results in a namespace error.
4.8) How do I undeclare the default XML namespace?
To "undeclare" the default XML namespace, you declare a default XML namespace with an empty (zero-length) name (URI). Within the scope of this declaration, unprefixed element type names do not belong to any XML namespace. For example, in the following, the default XML namespace is the http://www.foo.org/ for the A and B elements and there is no default XML namespace for the C and D elements. That is, the names A and B are in the http://www.foo.org/ namespace and the names C and D are not in any XML namespace.
<A xmlns="http://www.foo.org/">
<B>
<C xmlns="">
<D>abcd</D>
</C>
</B>
</A>
4.9) Why are special attributes used to declare XML namespaces?
I don't know the answer to this question, but the likely reason is that the hope that they would simplify the process of moving fragments from one document to another document. An early draft of the XML namespaces recommendation proposed using processing instructions to declare XML namespaces. While these were simple to read and process, they weren't easy to move to other documents. Attributes, on the other hand, are intimately attached to the elements being moved.
Unfortunately, this hasn't worked as well as was hoped. For example, consider the following XML document:
<foo:A xmlns:foo="http://www.foo.org/">
<foo:B>
<foo:C>bar</foo:C>
</foo:B>
</foo:A>
Simply using a text editor to cut the fragment headed by the <B> element from one document and paste it into another document results in the loss of namespace information because the namespace declaration is not part of the fragment -- it is on the parent element (<A>) -- and isn't moved.
Even when this is done programmatically, the situation isn't necessarily any better. For example, suppose an application uses DOM level 2 to "cut" the fragment from the above document and "paste" it into a different document. Although the namespace information is transferred (it is carried by each node), the namespace declaration (xmlns attribute) is not, again because it is not part of the fragment. Thus, the application must manually add the declaration before serializing the document or the new document will be invalid.
4.10) How do different XML technologies treat XML namespace declarations?
This depends on the technology -- some treat them as attributes and some treat them as namespace declarations. For example, SAX1 treats them as attributes and SAX2 can treat them as attributes or namespace declarations, depending on how the parser is configured. (For more information, see question 9.3 and the SAX2 documentation.) DOM levels 1 and 2 treat them as attributes, but DOM level 2 also interprets them as namespace declarations. (For more information, see question 9.5.) XPath, XSLT, and XML Schemas treat them as namespaces declarations.
The reason that different technologies treat these differently is that many of these technologies predate XML namespaces. Thus, newer versions of them need to worry both about XML namespaces and backwards compatibility issues.
5) SECTION 5: USING XML NAMESPACES IN AN XML DOCUMENT
5.1) How do I use prefixes to refer to element type and attribute names in an XML namespace?
Make sure you have declared the prefix (see question 4.1) and that it is still in scope (see section 6). All you need to do then is prefix the local name of an element type or attribute with the prefix and a colon. The result is a qualified name (see question 10.1), which the application parses to determine what XML namespace the local name belongs to.
For example, suppose you have associated the serv prefix with the http://www.tu-darmstadt.de/ito/servers namespace and that the declaration is still in scope. In the following, serv:Address refers to the Address name in the http://www.tu-darmstadt.de/ito/servers namespace. (Note that the prefix is used on both the start and end tags.)
<!-- serv refers to the http://www.tu-darmstadt.de/ito/servers namespace. -->
<serv:Address>123.45.67.8</serv:Address>
Now suppose you have associated the xslt prefix with the http://www.w3.org/1999/XSL/Transform namespace. In the following, xslt:version refers to the version name in the http://www.w3.org/1999/XSL/Transform namespace:
<!-- xslt refers to the http://www.w3.org/1999/XSL/Transform namespace. -->
<html xslt:version="1.0">
5.2) How do I use the default XML namespace to refer to element type names in an XML namespace?
Make sure you have declared the default XML namespace (see question 4.1) and that that declaration is still in scope (see section 6). All you need to do then is use the local name of an element type. Even though it is not prefixed, the result is still a qualified name (see question 10.1), which the application parses to determine what XML namespace it belongs to.
For example, suppose you declared the http://www.tu-darmstadt.de/ito/addresses namespace as the default XML namespace and that the declaration is still in scope. In the following, Address refers to the Address name in the http://www.tu-darmstadt.de/ito/addresses namespace.
<!-- http://www.tu-darmstadt.de/ito/addresses is the default XML namespace. -->
<Address>123.45.67.8</Address>
For information about how to use the default XML namespace with attribute names, see question 5.3.
5.3) How do I use the default XML namespace to refer to attribute names in an XML namespace?
You can't.
The default XML namespace only applies to element type names, so you can refer to attribute names that are in an XML namespace only with a prefix. For example, suppose that you declared the http://www.tu-darmstadt.de/ito/addresses namespace as the default XML namespace. In the following, the type attribute name does not refer to that namespace, although the Address element type name does. That is, the Address element type name is in the http://www.tu-darmstadt.de/ito/addresses namespace, but the type attribute name is not in any XML namespace.
<!-- http://www.tu-darmstadt.de/ito/addresses is the default XML namespace. -->
<Address type="home">
To understand why this is true, remember that the purpose of XML namespaces is to uniquely identify element and attribute names. Unprefixed attribute names can be uniquely identified based on the element type to which they belong, so there is no need identify them further by including them in an XML namespace. In fact, the only reason for allowing attribute names to be prefixed is so that attributes defined in one XML language can be used in another XML language.
For information about how to use the default XML namespace with element type names, see question 5.2. For more information about unprefixed attribute names and XML namespaces, see myth #4 in "Namespace Myths Exploded".
5.4) When should I use the default XML namespace instead of prefixes?
This is purely a matter of choice, although your choice may affect the readability of the document. When elements whose names all belong to a single XML namespace are grouped together, using a default XML namespace might make the document more readable. For example:
<!-- A, B, C, and G are in the http://www.foo.org/ namespace. -->
<A xmlns="http://www.foo.org/">
<B>abcd</B>
<C>efgh</C>
<!-- D, E, and F are in the http://www.bar.org/ namespace. -->
<D xmlns="http://www.bar.org/">
<E>1234</E>
<F>5678</F>
</D>
<!-- Remember! G is in the http://www.foo.org/ namespace. -->
<G>ijkl</G>
</A>
When elements whose names are in multiple XML namespaces are interspersed, default XML namespaces definitely make a document more difficult to read and prefixes should be used instead. For example:
<A xmlns="http://www.foo.org/">
<B xmlns="http://www.bar.org/">abcd</B>
<C xmlns="http://www.foo.org/">efgh</C>
<D xmlns="http://www.bar.org/">
<E xmlns="http://www.foo.org/">1234</E>
<F xmlns="http://www.bar.org/">5678</F>
</D>
<G xmlns="http://www.foo.org/">ijkl</G>
</A>
In some cases, default namespaces can be processed faster than namespace prefixes, but the difference is certain to be negligible in comparison to total processing time.
6) SECTION 6: SCOPE OF XML NAMESPACE DECLARATIONS
6.1) What is the scope of an XML namespace declaration?
The scope of an XML namespace declaration is that part of an XML document to which the declaration applies. An XML namespace declaration remains in scope for the element on which it is declared and all of its descendants, unless it is overridden or undeclared on one of those descendants (see questions 4.5, 4.6, and 4.8).
For example, in the following, the scope of the declaration of the http://www.foo.org/ namespace is the element A and its descendants (B and C). The scope of the declaration of the http://www.bar.org/ namespace is only the element C.
<foo:A xmlns:foo="http://www.foo.org/">
<foo:B>
<bar:C xmlns:bar="http://www.bar.org/" />
</foo:B>
</foo:A>
6.2) Does the scope of an XML namespace declaration include the element it is declared on?
Yes.
For example, in the following, the names B and C are in the http://www.bar.org/ namespace, not the http://www.foo.org/ namespace. This is because the declaration that associates the foo prefix with the http://www.bar.org/ namespace occurs on the B element, overriding the declaration on the A element that associates it with the http://www.foo.org/ namespace.
<foo:A xmlns:foo="http://www.foo.org/">
<foo:B xmlns:foo="http://www.bar.org/">
<foo:C>abcd</foo:C>
</foo:B>
</foo:A>
Similarly, in the following, the names B and C are in the http://www.bar.org/ namespace, not the http://www.foo.org/ namespace because the declaration declaring http://www.bar.org/ as the default XML namespace occurs on the B element, overriding the declaration on the A element.
<A xmlns="http://www.foo.org/">
<B xmlns="http://www.bar.org/">
<C>abcd</C>
</B>
</A>
A final example is that, in the following, the attribute name D is in the http://www.bar.org/ namespace.
<foo:A xmlns:foo="http://www.foo.org/">
<foo:B foo:D="In http://www.bar.org/ namespace"
xmlns:foo="http://www.bar.org/">
<C>abcd</C>
</foo:B>
</foo:A>
One consequence of XML namespace declarations applying to the elements they occur on is that they actually apply before they appear. Because of this, software that processes qualified names should be particularly careful to scan the attributes of an element for XML namespace declarations before deciding what XML namespace (if any) an element type or attribute name belongs to.
6.3) If an element or attribute is in the scope of an XML namespace declaration, is its name in that namespace?
Not necessarily.
When an element or attribute is in the scope of an XML namespace declaration, the element or attribute's name is checked to see if it has a prefix that matches the prefix in the declaration. Whether the name is actually in the XML namespace depends on whether the prefix matches. For example, in the following, the element type names A, B, and D and the attribute names C and E are in the scope of the declaration of the http://www.foo.org/ namespace. While the names A, B, and C are in that namespace, the names D and E are not.
<foo:A xmlns:foo="http://www.foo.org/">
<foo:B foo:C="foo" />
<bar:D bar:E="bar" />
</foo:A>
6.4) What happens when an XML namespace declaration goes out of scope?
When an XML namespace declaration goes out of scope, it simply no longer applies. For example, in the following, the declaration of the http://www.foo.org/ namespace does not apply to the C element because this is outside its scope. That is, it is past the end of the B element, on which the http://www.foo.org/ namespace was declared.
<!-- B is in the http://www.foo.org/ namespace; C is not in any XML namespace. -->
<A>
<B xmlns="http://www.foo.org/">abcd</B>
<C>efgh</C>
</A>
In addition to the declaration no longer applying, any declarations that it overrode come back into scope. For example, in the following, the declaration of the http://www.foo.org/ namespace is brought back into scope after the end of the B element. This is because it was overridden on the B element by the declaration of the http://www.bar.org/ namespace.
<!-- A and C are in the http://www.foo.org/ namespace. B is in the http://www.bar.org/ namespace. -->
<A xmlns="http://www.foo.org/">
<B xmlns="http://www.bar.org/">abcd</B>
<C>efgh</C>
</A>
6.5) What happens if no XML namespace declaration is in scope?
If no XML namespace declaration is in scope, then any prefixed element type or attribute names result in namespace errors. For example, in the following, the names foo:A and foo:B result in namespace errors.
<?xml version="1.0" ?>
<foo:A foo:B="error" />
In the absence of an XML namespace declaration, unprefixed element type and attribute names do not belong to any XML namespace. For example, in the following, the names A and B are not in any XML namespace. For more information, see question 3.5.
<?xml version="1.0" ?>
<A B="no error" />
6.6) Can multiple XML namespace declarations be in scope at the same time?
Yes, as long as they don't use the same prefixes and at most one of them is the default XML namespace. For example, in the following, the http://www.foo.org/ and http://www.bar.org/ namespaces are both in scope for all elements:
<A xmlns:foo="http://www.foo.org/"
xmlns:bar="http://www.bar.org/">
<foo:B>abcd</foo:B>
<bar:C>efgh</bar:C>
</A>
One consequence of this is that you can place all XML namespace declarations on the root element and they will be in scope for all elements. This is the simplest way to use XML namespaces.
6.7) How can I declare XML namespaces so that all elements and attributes are in their scope?
XML namespace declarations that are made on the root element are in scope for all elements and attributes in the document. This means that an easy way to declare XML namespaces is to declare them only on the root element. For example:
<Department
xmlns:addr="http://www.tu-darmstadt.de/ito/addresses"
xmlns:serv="http://www.tu-darmstadt.de/ito/servers">
<Name>DVS1</Name>
<addr:Address>
<addr:Street>Wilhelminenstr. 7</addr:Street>
<addr:City>Darmstadt</addr:City>
<addr:State>Hessen</addr:State>
<addr:Country>Germany</addr:Country>
<addr:PostalCode>D-64285</addr:PostalCode>
</addr:Address>
<serv:Server>
<serv:Name>OurWebServer</serv:Name>
<serv:Address>123.45.67.8</serv:Address>
</serv:Server>
</Department>
6.8) Does the scope of an XML namespace declaration ever include the DTD?
No.
XML namespaces can be declared only on elements and their scope consists only of those elements and their descendants. Thus, the scope can never include the DTD. For more information, see question 7.2.
7) SECTION 7: XML NAMESPACES AND DTDs
7.1) Can I use XML namespaces in DTDs?
Yes and no.
In particular, DTDs can contain qualified names (see question 7.3) but XML namespace declarations do not apply to DTDs (see question 7.2).
This has a number of consequences. Because XML namespace declarations do not apply to DTDs:
There is no way to determine what XML namespace a prefix in a DTD points to. Which means...
Qualified names in a DTD cannot be mapped to universal names. Which means...
Element type and attribute declarations in a DTD are expressed in terms of qualified names, not universal names. Which means...
Validation cannot be redefined in terms of universal names as might be expected.
This situation has caused numerous complaints but, as XML namespaces are already a recommendation, is unlikely to change. The long term solution to this problem is an XML schema language: all of the proposed XML schema languages provide a mechanism by which the local name in an element type or attribute declaration can be associated with an XML namespace. This makes it possible to redefine validity in terms of universal names.
7.2) Do XML namespace declarations apply to DTDs?
No.
In particular, an xmlns attribute declared in the DTD with a default is not an XML namespace declaration for the DTD. For more information, see question 4.4. (Note that an earlier version of MSXML (the parser used by Internet Explorer) did use such declarations as XML namespace declarations, but that this was removed in MSXML 4. For more information, see question 8.6.)
7.3) Can I use qualified names in DTDs?
Yes.
For example, the following is legal:
<!ELEMENT foo:A (foo:B)>
<!ATTLIST foo:A
foo:C CDATA #IMPLIED>
<!ELEMENT foo:B (#PCDATA)>
However, because XML namespace declarations do not apply to DTDs (see question 7.2), qualified names in the DTD cannot be converted to universal names. As a result, qualified names in the DTD have no special meaning. For example, foo:A is just foo:A -- it is not A in the XML namespace to which the prefix foo is mapped.
The reason qualified names are allowed in the DTD is so that validation will continue to work. For more information, see question 7.6.
7.4) Can the content model in an element type declaration contain element types whose names come from other XML namespaces?
Yes and no.
The answer to this question is yes in the sense that a qualified name in a content model can have a different prefix than the qualified name of the element type being declared. For example, the following is legal:
<!ELEMENT foo:A (bar:B, baz:C)>
The answer to this question is no in the sense that XML namespace declarations do not apply to DTDs so the prefixes used in an element type declaration are technically meaningless. In particular, they do not specify that the name of a certain element type belongs to a certain namespace. Nevertheless, the ability to mix prefixes in this manner is crucial when: a) you have a document whose names come from multiple XML namespaces (see question 8.5), and b) you want to construct that document in a way that is both valid and conforms to the XML namespaces recommendation (see question 7.6).
7.5) Can the attribute list of an element type contain attributes whose names come from other XML namespaces?
Yes and no, for the reasons listed in question 7.4.
For example, the following is legal:
<!ATTLIST foo:A
bar:B CDATA #IMPLIED>
7.6) How can I construct an XML document that is valid and conforms to the XML namespaces recommendation?
In answering this question, it is important to remember that:
Validity is a concept defined in XML 1.0,
XML namespaces are layered on top of XML 1.0 (see myth #11 in "Namespace Myths Exploded"), and
The XML namespaces recommendation does not redefine validity, such as in terms of universal names (see myth #9 in "Namespace Myths Exploded").
Thus, validity is the same for a document that uses XML namespaces and one that doesn't. In particular, with respect to validity:
xmlns attributes are treated as attributes, not XML namespace declarations.
Qualified names are treated like other names. For example, in the name foo:A, foo is not treated as a namespace prefix, the colon is not treated as separating a prefix from a local name, and A is not treated as a local name. The name foo:A is treated simply as the name foo:A.
Because of this, XML documents that you might expect to be valid are not. For example, the following document is not valid because the element type name A is not declared in the DTD, in spite of the fact both foo:A and A share the universal name {http://www.foo.org/}A:
<?xml version="1.0" ?>
<!DOCTYPE foo:A [
<!ELEMENT foo:A (#PCDATA)>
<!ATTLIST foo:A
xmlns:foo CDATA #FIXED "http://www.foo.org/"
xmlns CDATA #FIXED "http://www.foo.org/">
]>
<A/>
Similarly, the following is not valid because the xmlns attribute is not declared in the DTD:
<?xml version="1.0" ?>
<!DOCTYPE A [
<!ELEMENT A (#PCDATA)>
]>
<A xmlns="http://www.foo.org/" />
Furthermore, documents that you might expect to be invalid are valid. For example, the following document is valid but contains two definitions of the element type with the universal name {http://www.foo.org/}A:
<?xml version="1.0" ?>
<!DOCTYPE foo:A [
<!ELEMENT foo:A (bar:A)>
<!ATTLIST foo:A
xmlns:foo CDATA #FIXED "http://www.foo.org/">
<!ELEMENT bar:A (#PCDATA)>
<!ATTLIST bar:A
xmlns:bar CDATA #FIXED "http://www.foo.org/">
]>
<foo:A>
<bar:A>abcd</bar:A>
</foo:A>
Finally, validity has nothing to do with correct usage of XML namespaces. For example, the following document is valid but does not conform to the XML namespaces recommendation because the foo prefix is never declared:
<?xml version="1.0" ?>
<!DOCTYPE foo:A [
<!ELEMENT foo:A (#PCDATA)>
]>
<foo:A />
Therefore, when constructing an XML document that uses XML namespaces, you need to do both of the following if you want the document to be valid:
Declare xmlns attributes in the DTD.
Use the same qualified names in the DTD and the body of the document.
For example:
<?xml version="1.0" ?>
<!DOCTYPE foo:A [
<!ELEMENT foo:A (foo:B)
<!ATTLIST foo:A
xmlns:foo CDATA #FIXED "http://www.foo.org/">
<!ELEMENT foo:B (#PCDATA)>
]>
<foo:A>
<foo:B>abcd</foo:B>
</foo:A>
There is no requirement that the same prefix always be used for the same XML namespace. For example, the following is also valid:
<?xml version="1.0" ?>
<!DOCTYPE foo:A [
<!ELEMENT foo:A (bar:B)>
<!ATTLIST foo:A
xmlns:foo CDATA #FIXED "http://www.foo.org/">
<!ELEMENT bar:B (#PCDATA)>
<!ATTLIST bar:B
xmlns:bar CDATA #FIXED "http://www.foo.org/">
]>
<foo:A>
<bar:B />
</foo:A>
However, documents that use multiple prefixes for the same XML namespace or the same prefix for multiple XML namespaces are confusing to read and thus prone to error. They also allow abuses such as defining an element type or attribute with a given universal name more than once, as was seen earlier. Therefore, a better set of guidelines for writing documents that are both valid and conform to the XML namespaces recommendation is:
Declare all xmlns attributes in the DTD.
Use the same qualified names in the DTD and the body of the document.
Use one prefix per XML namespace.
Do not use the same prefix for more than one XML namespace.
Use at most one default XML namespace.
The latter three guidelines guarantee that prefixes are unique. This means that prefixes fulfill the role normally played by namespace names (URIs) -- uniquely identifying an XML namespace -- and that qualified names are equivalent to universal names, so a given universal name is always represented by the same qualified name. Although this is contrary to the spirit of prefixes, which were designed for their flexibility, there is no other solution at this point.
7.7) How can I validate an XML document that uses XML namespaces?
When people ask this question, they usually assume that validity is different for documents that use XML namespaces and documents that don't. In fact, it isn't -- it's the same for both. Thus, there is no difference between validating a document that uses XML namespaces and validating one that doesn't. In either case, you simply use a validating parser or other software that performs validation.
For information about how to construct an XML document that is valid and conforms to the XML namespace recommendation, see question 7.6.
7.8) If I start using XML namespaces, do I need to change my existing DTDs?
Probably.
If you want your XML documents to be both valid and conform to the XML namespaces recommendation, you need to declare any xmlns attributes and use the same qualified names in the DTD as in the body of the document. (For more information, see question question 7.6.)
If your DTD contains element type and attribute names from a single XML namespace, the easiest thing to do is to use your XML namespace as the default XML namespace. To do this, declare the attribute xmlns (no prefix) for each possible root element type. If you can guarantee that the DTD is always read (see question 4.3), set the default value in each xmlns attribute declaration to the URI used as your namespace name. Otherwise, declare your XML namespace as the default XML namespace on the root element of each instance document.
If your DTD contains element type and attribute names from multiple XML namespaces, you need to choose a single prefix for each XML namespace and use these consistently in qualified names in both the DTD and the body of each document. You also need to declare your xmlns attributes in the DTD and declare your XML namespaces. As in the single XML namespace case, the easiest way to do this is add xmlns attributes to each possible root element type and use default values if possible.
Note that you should only need to make these changes once.
8) SECTION 8: USING DOCUMENTS THAT USE XML NAMESPACES
8.1) How do I create documents that use XML namespaces?
The same as you create documents that don't use XML namespaces. If you're currently using Notepad on Windows or emacs on Linux, you can continue using Notepad or emacs. If you're using an XML editor that is not namespace-aware, you can also continue to use that, as qualified names are legal names in XML documents and xmlns attributes are legal attributes. And if you're using an XML editor that is namespace-aware, it will probably provide features such as automatically declaring XML namespaces and keeping track of prefixes and the default XML namespace for you.
8.2) How can I check that a document conforms to the XML namespaces recommendation?
Unfortunately, I know of no software that only checks for conformance to the XML namespaces recommendation. It is possible that some namespace-aware validating parsers (such as those from DataChannel (Microsoft), IBM, Oracle, or Sun) check XML namespace conformance as part of parsing and validating. Thus, you might be able to run your document through such parsers as a way of testing conformance.
Note that writing an application to check conformance to the XML namespaces recommendation is not as easy as it might seem. The problem is that most parsers do not make DTD information available to the application, so it might not be possible to check conformance in the DTD. Also note that writing a SAX 1.0 application that checks conformance in the body of the document (as opposed to the DTD) should be an easy thing to do. (John Cowan's Namespace SAX Filter probably already does this. For more information, see question 9.2.)
8.3) Can I use the same document with both namespace-aware and namespace-unaware applications?
Yes.
This situation is quite common, such as when a namespace-aware application is built on top of a namespace-unaware parser. Another common situation is when you create an XML document with a namespace-unaware XML editor but process it with a namespace-aware application.
Using the same document with both namespace-aware and namespace-unaware applications is possible because XML namespaces use XML syntax. That is, an XML document that uses XML namespaces is still an XML document and is recognized as such by namespace-unaware software.
The only thing you need to be careful about when using the same document with both namespace-aware and namespace-unaware applications is when the namespace-unaware application requires the document to be valid. In this case, you must be careful to construct your document in a way that is both valid and conforms to the XML namespaces recommendation. (It is possible to construct documents that conform to the XML namespaces recommendation but are not valid and vice versa.) For information about how to do this, see question 7.6.
8.4) What software is needed to process XML namespaces?
From a document author's perspective, this is generally not a relevant question. Most XML documents are written in a specific XML language and processed by an application that understands that language. If the language uses an XML namespace, then the application will already use that namespace -- there is no need for any special XML namespace software.
For information about the software application writers use to process XML namespaces, see section 9.
8.5) How can I use XML namespaces to combine documents that use different element type and attribute names?
Before we answer this question, we need to clear up a common misconception about XML namespaces. It is often believed that XML namespaces provide some sort of magic that allows you to automatically combine XML documents that use separate sets of element types and attributes. This is not true. Although XML namespaces provide some of the tools you need to do this, you still need to do most of the work yourself, as you will see in the answer to this question.
To combine documents that use separate sets of element types and attributes, all you really need to do is decide where the elements and attributes go in the final document. For example, does element type A from the first document go inside element type B? Is it a sibling? Or are they completely unrelated? Although the procedure for actually combining two documents can be easily automated, deciding how to combine them is not likely to ever be automated. Instead, it is a strictly human problem, requiring somebody to make choices.
For example, suppose we have a document containing addresses:
<Address>
<Street>Wilhelminenstr. 7</Street>
<City>Darmstadt</City>
<State>Hessen</State>
<Country>Germany</Country>
<PostalCode>D-64285</PostalCode>
</Address>
and a document containing Web server information:
<Server>
<Name>OurWebServer</Name>
<Address>123.45.67.8</Address>
</Server>
Now suppose we would like a document of departments, their addresses, and their Web servers, which we can make from the above documents plus a little additional information:
<Departments>
<Department>
<Name>DVS1</Name>
<Address>
<Street>Wilhelminenstr. 7</Street>
<City>Darmstadt</City>
<State>Hessen</State>
<Country>Germany</Country>
<PostalCode>D-64285</PostalCode>
</Address>
<Server>
<Name>OurWebServer</Name>
<Address>123.45.67.8</Address>
</Server>
</Department>
...
</Departments>
Unfortunately, we have a problem: there are two Address element types and two Name element types. (Although the Name element types both have a content model of PCDATA, they have different meanings -- one is the name of the department and the other is the name of the server -- so we would like to recognize them as different element types.)
To solve these conflicts, we can use XML namespaces. We assign the address information to the http://www.tu-darmstadt.de/ito/addresses namespace, the server information to the http://www.tu-darmstadt.de/ito/servers namespace, and the newly added departmental information to the http://www.tu-darmstadt.de/ito/depts namespace. Thus, our new document looks like:
<dept:Departments
xmlns:dept="http://www.tu-darmstadt.de/ito/depts
xmlns:addr="http://www.tu-darmstadt.de/ito/addresses
xmlns:serv="http://www.tu-darmstadt.de/ito/servers>
<dept:Department>
<dept:Name>DVS1</dept:Name>
<addr:Address>
<addr:Street>Wilhelminenstr. 7</addr:Street>
<addr:City>Darmstadt</addr:City>
<addr:State>Hessen</addr:State>
<addr:Country>Germany</addr:Country>
<addr:PostalCode>D-64285</addr:PostalCode>
</addr:Address>
<serv:Server>
<serv:Name>OurWebServer</serv:Name>
<serv:Address>123.45.67.8</serv:Address>
</serv:Server>
</dept:Department>
...
</dept:Departments>
Although we could have assigned only the conflicting element type names to XML namespaces, it is generally a better idea to keep the names of related element types in a single XML namespace. This avoids questions of having to remember which names have been placed in XML namespaces and which haven't, as well as avoiding future conflicts that might occur when these types are used elsewhere. (This does not necessarily mean that the names of all related element types and attributes should be placed in a single XML namespace. If you have a large and complex set of element types and attributes and expect to reuse subsets of it elsewhere, it might make more sense to place the names of each reusable subset in its own XML namespace.)
This example was fairly simple in that it did not require us to change any existing content models. However, suppose we wanted to keep information only about servers: their name, IP address, and physical location. In this case, we might want to add the Address element type that describes street address to the content of the Server element type:
<serv:Servers
xmlns:addr="http://www.tu-darmstadt.de/ito/addresses
xmlns:serv="http://www.tu-darmstadt.de/ito/servers2>
<serv:Server>
<serv:Name>OurWebServer</serv:Name>
<serv:Address>123.45.67.8</serv:Address>
<addr:Address>
<addr:Street>Wilhelminenstr. 7</addr:Street>
<addr:City>Darmstadt</addr:City>
<addr:State>Hessen</addr:State>
<addr:Country>Germany</addr:Country>
<addr:PostalCode>D-64285</addr:PostalCode>
</addr:Address>
</serv:Server>
...
</serv:Servers>
Notice that we have changed the name of the XML namespace for the server information to http://www.tu-darmstadt.de/ito/servers2. This is because we changed the content model of the Server element type. In other words, the content models of the two Server element types are different, so they are two different element types with the same name and should reside in separate XML namespaces. Had we not made this change, software searching for the old Server element type would have incorrectly processed the new Server element type and vice versa.
As you can see, there is nothing magic about combining documents. It is simply a matter of deciding how to fit them together and, although there are likely to be tools in the future that make this as easy as drag-and-drop, the decisions about exactly how to combine them are likely to always require human intervention.
You can also see that XML namespaces played a vital role in this process -- they allowed us to combine the documents without changing the local names of any of the element types. This is important, as without XML namespaces we would endlessly have to invent new ways of renaming simple element types like Address. However, it is also important to understand that resolving duplicate names is the only role XML namespaces played in this process -- the rest was left to the people making the decisions.
8.6) How do I use XML namespaces with Internet Explorer 5.0 and/or the MSXML parser?
WARNING! The following applies only to earlier versions of MSXML. It does not apply to MSXML 4, which is the currently shipping version [July, 2002].
An early version of the MSXML parser, which was shipped as part of Internet Explorer 5.0, required that every XML namespace prefix used in an element type or attribute declaration had to be "declared" in the attribute declaration for that element type. This had to be done with a fixed xmlns attribute declaration. For example, the following was accepted by MSXML and both xmlns:foo attributes were required:
<!ELEMENT foo:A (#PCDATA)>
<!ATTLIST foo:A
xmlns:foo CDATA #FIXED "http://www.foo.org/">
<!ELEMENT foo:B (#PCDATA)>
<!ATTLIST foo:B
xmlns:foo CDATA #FIXED "http://www.foo.org/">
MSXML returned an error for the following because the second foo prefix was not "declared":
<!ELEMENT foo:A (#PCDATA)>
<!ATTLIST foo:A
xmlns:foo CDATA #FIXED "http://www.foo.org/">
<!ELEMENT foo:B (#PCDATA)>
The reason for this restriction was so that MSXML could use universal names to match element type and attribute declarations to elements and attributes during validation. Although this would have simplified many of the problems of writing documents that are both valid and conform to the XML namespaces recommendation (see question 7.6), some users complained about it because it was not part of the XML namespaces recommendation. In response to these complaints, Microsoft removed this restriction in later versions, which are now shipping. Ironically, the idea was later independently derived as a way to resolve the problems of validity and namespaces. However, it has not been implemented by anyone.
9) SECTION 9: PROCESSING XML NAMESPACES IN XML APPLICATIONS
9.1) How do applications process documents that use XML namespaces?
Applications process documents that use XML namespaces in almost exactly the same way they process documents that don't use XML namespaces. For example, if a namespace-unaware application adds a new sales order to a database when it encounters a SalesOrder element, the equivalent namespace-aware application does the same. The only difference is that the namespace-aware application:
Might need to check for xmlns attributes and parse qualified names. Whether it does this depends on whether such processing is already done by lower-level software, such as a namespace-aware DOM implementation.
Uses universal (two-part) names instead of local (one-part) names. For example, the namespace-aware application might add a new sales order in response to an {http://www.tu-darmstadt.de/ito/sales}SalesOrder element instead of a SalesOrder element.
9.2) How do I use XML namespaces with SAX 1.0?
The easiest way to use XML namespaces with SAX 1.0 is to use John Cowan's Namespace SAX Filter (see http://www.ccil.org/~cowan/XML). This is a SAX filter that keeps track of XML namespace declarations, parses qualified names, and returns element type and attribute names as universal names in the form:
URI^local-name
For example:
http://www.tu-darmstadt.de/ito/sales^SalesOrder
Your application can then base its processing on these longer names. For example, the code:
public void startElement(String elementName, AttributeList attrs)
throws SAXException
{
...
if (elementName.equals("SalesOrder"))
{
// Add new database record.
}
...
}
might become:
public void startElement(String elementName, AttributeList attrs)
throws SAXException
{
...
if (elementName.equals("http://www.tu-darmstadt.de/sales^SalesOrder"))
{
// Add new database record.
}
...
}
or:
public void startElement(String elementName, AttributeList attrs)
throws SAXException
{
...
// getURI() and getLocalName() are utility functions to parse universal names.
if (getURI(elementName).equals("http://www.tu-darmstadt.de/ito/sales"))
{
if (getLocalName(elementName).equals("SalesOrder"))
{
// Add new database record.
}
}
...
}
If you do not want to use the Namespace SAX Filter, then you will need to do the following in addition to identifying element types and attributes by their universal names:
In startElement, scan the attributes for XML namespace declarations before doing any other processing. You will need to maintain a table of current prefix-to-URI mappings (including a null prefix for the default XML namespace).
In startElement and endElement, check whether the element type name includes a prefix. If so, use your mappings to map this prefix to a URI. Depending on how your software works, you might also check if the local part of the qualified name includes any colons, which are illegal.
In startElement, check whether attribute names include a prefix. If so, process as in the previous point.
9.3) How do I use XML namespaces with SAX 2.0?
SAX 2.0 primarily supports XML namespaces through the following methods:
startElement and endElement in the ContentHandler interface return namespace names (URIs) and local names as well as qualified names.
getValue, getType, and getIndex in the Attributes interface can retrieve attribute information by namespace name (URI) and local name as well as by qualified name.
For example, the namespace-unaware SAX 1.0 code:
public void startElement(String elementName, AttributeList attrs)
throws SAXException
{
...
if (elementName.equals("SalesOrder"))
{
// Add new database record.
}
...
}
might become:
public void startElement(String namespaceURI,
String localName,
String qualifiedName,
Attributes attrs)
throws SAXException
{
...
if (namespaceURI.equals("http://www.tu-darmstadt.de/sales") &&
localName.equals("SalesOrder"))
{
// Add new database record.
}
...
}
Although the above methods are sufficient for most applications, SAX 2.0 also supports the following:
startPrefixMapping and endPrefixMapping in the ContentHandler interface return scope information about individual prefixes.
getURI, getLocalName, and getQName in the Attributes interface return the namespace name (URI), local name, and qualified name of an attribute by index.
The http://xml.org/features/namespaces and http://xml.org/features/namespace-prefixes properties allow applications to request whether parsers return qualified names and xmlns attributes.
The NamespaceSupport class helps applications track the currently declared namespace prefixes and names (URIs).
For complete details, see the SAX 2.0 specification (http://www.saxproject.org/).
9.4) How do I use XML namespaces with DOM level 1?
This depends on what DOM level 1 implementation you are using. If you are using a namespace-aware DOM implementation, such as those from Data Channel (Microsoft), IBM, Oracle, or Sun, then all you need to do is use the methods provided by those implementations to retrieve the namespace name (URI) and local names. For example, the namespace-unaware code:
// Check the local name.
// getNodeName() is a DOM level 1 method.
if (elementNode.getNodeName().equals("SalesOrder"))
{
// Add new database record.
}
might become the following namespace-aware code when using Oracle's DOM implementation:
// Check the XML namespace name (URI).
// getNamespace() and NSElement are Oracle-specific.
if ((NSElement)elementNode).getNamespace().equals("http://www.tu-darmstadt.de/ito/sales"))
{
// Check the local name.
// getLocalName() is Oracle-specific.
if ((NSElement)elementNode.getLocalName().equals("SalesOrder"))
{
// Add new database record.
}
}
Because DOM level 1 does not include XML namespace support, each DOM level 1 implementation provides a slightly different interface for accessing XML namespace information. Most of these implementations include some combination of methods for getting the qualified name, namespace name (URI), local name, and prefix. Therefore, if you are writing a DOM-neutral application, you will need to define your own XML namespace interface and write converters for each DOM implementation you support. Fortunately, this is easy to do.
If you are using a namespace-unaware DOM implementation, such as Docuverse version 1 or OpenXML version 1 (these may support XML namespaces in a later version), you will need to perform namespace processing yourself. Although this is largely the same as in a SAX 1.0 application (see question 9.2) -- checking for xmlns attributes on each Element node and converting qualified names on Element and Attr nodes to universal names -- it is potentially more difficult to determine what XML namespace declarations are in scope for any given node. If your application traverses the DOM tree in order from the root, this is fairly easy, as you can maintain prefix-to-URI mappings as you go. However, if you access the tree randomly, you may want to construct a parallel tree with mapping information before you do any other processing or rebuild the DOM tree using prefixes that map to known URIs.
9.5) How do I use XML namespaces with DOM level 2?
DOM level 2 supports XML namespaces through a number of new methods and attributes. The most important of these are the namespaceURI and localName attributes in the Node interface; these allow applications to identify nodes by their namespace name (URI) and local name rather than by qualified name. For example, the namespace-unaware code:
// Check the local name.
// getNodeName() is a DOM level 1 method.
if (elementNode.getNodeName().equals("SalesOrder"))
{
// Add new database record.
}
might become the following namespace-aware code:
// Check the XML namespace name (URI).
// getNamespaceURI() is a DOM level 2 method.
if (elementNode.getNamespaceURI().equals("http://www.tu-darmstadt.de/ito/sales"))
{
// Check the local name.
// getLocalName() is a DOM level 2 method.
if (elementNode.getLocalName().equals("SalesOrder"))
{
// Add new database record.
}
}
Note that, unlike SAX 2.0, DOM level 2 treats xmlns attributes as normal attributes.
For complete details, see the DOM level 2 recommendation (http://www.w3.org/TR/DOM-Level-2/).
9.6) Can an application process documents that use XML namespaces and documents that don't use XML namespaces?
Yes.
This is a common situation for generic applications, such as editors, browsers, and parsers, that are not wired to understand a particular XML language. Such applications simply treat all element type and attribute names as qualified names. Those names that are not mapped to an XML namespace -- that is, unprefixed element type names in the absence of a default XML namespace and unprefixed attribute names -- are simply processed as one-part names, such as by using a null XML namespace name (URI).
Note that such applications must decide how to treat documents that do not conform to the XML namespaces recommendation. For example, what should the application do if an element type name contains a colon (thus implying the existence of a prefix), but there are no XML namespace declarations in the document? The application can choose to treat this as an error, or it can treat the document as one that does not use XML namespaces, ignore the "error", and continue processing.
9.7) Can an application be both namespace-aware and namespace-unaware?
Yes.
However, there is generally no reason to do this. The reason is that most applications understand a particular XML language, such as one used to transfer sales orders between companies. If the element type and attribute names in the language belong to an XML namespace, the application must be namespace-aware; if not, the application must be namespace-unaware. For example, such an application should never need to recognize the element type names SalesOrder and {http://www.tu-darmstadt.de/ito/sales}SalesOrder.
For a few applications, being both namespace-aware and namespace-unaware makes sense. For example, a parser might choose to redefine validity in terms of universal names (see myth #9 in "Namespace Myths Exploded") and have both namespace-aware and namespace-unaware validation modes. However, such applications are uncommon.
9.8) What does a namespace-aware application do when it encounters an error?
The XML namespaces recommendation does not specify what a namespace-aware application does when it encounters a document that does not conform to the recommendation. Therefore, the behavior is application-dependent. For example, the application could stop processing, post an error to a log and continue processing, or ignore the error.
[返回] 中文XML论坛 - 专业的XML技术讨论区 →
XML.ORG.CN讨论区 - XML技术 → 『 XML基础 』 → [转载]XML Namespaces FAQ
(订阅本版)
2004/2/25 11:21:00
新浪微博
[转载]XML Namespaces FAQ
