Set - 4

Question 1 :

How do I use the default XML namespace to refer to attribute names in an XML namespace?

Answer :

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://http://www.w3.org/to/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://http://www.fyicneter.com/ito/addresses namespace, but the type attribute name is not in any XML namespace.

<!-- http://http://www.w3.org/to/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.


Question 2 :

When should I use the default XML namespace instead of prefixes?

Answer :

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.google.org/ namespace. -->
<A xmlns="http://www.google.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.google.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.google.org/">
<B xmlns="http://www.bar.org/">abcd</B>
<C xmlns="http://www.google.org/">efgh</C>
<D xmlns="http://www.bar.org/">
<E xmlns="http://www.google.org/">1234</E>
<F xmlns="http://www.bar.org/">5678</F>
</D>
<G xmlns="http://www.google.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.


Question 3 :

What is the scope of an XML namespace declaration?

Answer :

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. 
For example, in the following, the scope of the declaration of the http://www.google.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.

<google:A xmlns:google="http://www.google.org/">
<google:B>
<bar:C xmlns:bar="http://www.bar.org/" />
</google:B>
</google:A>


Question 4 :

Does the scope of an XML namespace declaration include the element it is declared on?

Answer :

Yes. 
For example, in the following, the names B and C are in the http://www.bar.org/ namespace, not the http://www.google.org/ namespace. This is because the declaration that associates the google 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.google.org/ namespace.

<google:A xmlns:google="http://www.google.org/">
<google:B xmlns:google="http://www.bar.org/">
<google:C>abcd</google:C>
</google:B>
</google:A>

Similarly, in the following, the names B and C are in the http://www.bar.org/ namespace, not the http://www.google.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.google.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.

<google:A xmlns:google="http://www.google.org/">
<google:B google:D="In http://www.bar.org/ namespace"
xmlns:google="http://www.bar.org/">
<C>abcd</C>
</google:B>
</google: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.


Question 5 :

If an element or attribute is in the scope of an XML namespace declaration, is its name in that namespace?

Answer :

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.google.org/ namespace. While the names A, B, and C are in that namespace, the names D and E are not.

<google:A xmlns:google="http://www.google.org/">
<google:B google:C="google" />
<bar:D bar:E="bar" />
</google:A>


Question 6 :

What happens when an XML namespace declaration goes out of scope?

Answer :

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.google.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.google.org/ namespace was declared.

<!-- B is in the http://www.google.org/ namespace;
C is not in any XML namespace. -->
<A>
<B xmlns="http://www.google.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.google.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.google.org/ namespace.
B is in the http://www.bar.org/ namespace. -->
<A xmlns="http://www.google.org/">
<B xmlns="http://www.bar.org/">abcd</B>
<C>efgh</C>
</A>


Question 7 :

What happens if no XML namespace declaration is in scope?

Answer :

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 google:A and google:B result in namespace errors. 

<?xml version="1.0" ?>
<google:A google: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.


Question 8 :

Can multiple XML namespace declarations be in scope at the same time?

Answer :

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.google.org/ and http://www.bar.org/ namespaces are both in scope for all elements:

<A xmlns:google="http://www.google.org/"
xmlns:bar="http://www.bar.org/">
<google:B>abcd</google: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.


Question 9 :

How can I declare XML namespaces so that all elements and attributes are in their scope?

Answer :

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.


Question 10 :

Does the scope of an XML namespace declaration ever include the DTD?

Answer :

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.


Question 11 :

Can I use XML namespaces in DTDs?

Answer :

Yes and no.
In particular, DTDs can contain qualified names but XML namespace declarations do not apply to DTDs .
This has a number of consequences. Because XML namespace declarations do not apply to DTDs:
1. There is no way to determine what XML namespace a prefix in a DTD points to. Which means...
2. Qualified names in a DTD cannot be mapped to universal names. Which means...
3. Element type and attribute declarations in a DTD are expressed in terms of qualified names, not universal names. Which means...
4. 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.


Question 12 :

Do XML namespace declarations apply to DTDs?

Answer :

No.
In particular, an xmlns attribute declared in the DTD with a default is not an XML namespace declaration for the DTD.. (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.


Question 13 :

Can I use qualified names in DTDs?

Answer :

Yes. 
For example, the following is legal:

<!ELEMENT google:A (google:B)>
<!ATTLIST google:A
google:C CDATA #IMPLIED>
<!ELEMENT google:B (#PCDATA)>

However, because XML namespace declarations do not apply to DTDs , 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, google:A is just google:A -- it is not A in the XML namespace to which the prefix google is mapped. 
The reason qualified names are allowed in the DTD is so that validation will continue to work.


Question 14 :

Can the content model in an element type declaration contain element types whose names come from other XML namespaces?

Answer :

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 google: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 , and b) you want to construct that document in a way that is both valid and conforms to the XML namespaces recommendation .


Question 15 :

Can the attribute list of an element type contain attributes whose names come from other XML namespaces? 

Answer :

Yes and no. 
For example, the following is legal:

<!ATTLIST google:A  bar:B CDATA #IMPLIED>


Question 16 :

How can I construct an XML document that is valid and conforms to the XML namespaces recommendation?

Answer :

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 , and
* The XML namespaces recommendation does not redefine validity, such as in terms of universal names .
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 google:A, google 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 google:A is treated simply as the name google: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 google:A and A share the universal name {http://www.google.org/}A:

<?xml version="1.0" ?>
<!DOCTYPE google:A [
<!ELEMENT google:A EMPTY>
<!ATTLIST google:A xmlns:google CDATA #FIXED "http://www.google.org/" xmlns CDATA #FIXED "http://www.google.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 EMPTY>
]>
<A xmlns="http://www.google.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.google.org/}A:

<?xml version="1.0" ?>
<!DOCTYPE google:A [
<!ELEMENT google:A (bar:A)>
<!ATTLIST google:A
xmlns:google CDATA #FIXED "http://www.google.org/">
<!ELEMENT bar:A (#PCDATA)>
<!ATTLIST bar:A
xmlns:bar CDATA #FIXED "http://www.google.org/">
]>
<google:A>
<bar:A>abcd</bar:A>
</google: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 google prefix is never declared: 

<?xml version="1.0" ?>
<!DOCTYPE google:A [
<!ELEMENT google:A EMPTY>
]>
<google: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 google:A [
<!ELEMENT google:A (google:B)
<!ATTLIST google:A xmlns:google CDATA #FIXED "http://www.google.org/">
<!ELEMENT google:B EMPTY>
]>
<google:A>
<google:B />
</google: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 google:A [
<!ELEMENT google:A (bar:B)>
<!ATTLIST google:A
xmlns:google CDATA #FIXED "http://www.google.org/">
<!ELEMENT bar:B EMPTY>
<!ATTLIST bar:B
xmlns:bar CDATA #FIXED "http://www.google.org/">
]>
<google:A>
<bar:B />
</google: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. Unfortunately, this is contrary to the spirit of prefixes, which were designed for their flexibility. For a slightly better solution.


Question 17 :

How can I allow the prefixes in my document to be different from the prefixes in my DTD?

Answer :

One of the problems with the solution proposed in question is that it requires the prefixes in the document to match those in the DTD. Fortunately, there is a workaround for this problem, although it does require that a single prefix be used for a particular namespace URI throughout the document. (This is a good practice anyway, so it's not too much of a restriction.) The solution assumes that you are using a DTD that is external to the document, which is common practice. 
To use different prefixes in the external DTD and XML documents, you declare the prefix with a pair of parameter entities in the DTD. You can then override these entities with declarations in the internal DTD in a given XML document. This works because the internal DTD is read before the external DTD and the first definition of a particular entity is the one that is used. The following paragraphs describe how to use a single namespace in your DTD. You will need to modify them somewhat to use multiple namespaces. 
To start with, declare three parameter entities in your DTD:

<!ENTITY % p "" >
<!ENTITY % s "" >
<!ENTITY % nsdecl "xmlns%s;" >

The p entity ("p" is short for "prefix") is used in place of the actual prefix in element type and attribute names. The s entity ("s" is short for "suffix") is used in place of the actual prefix in namespace declarations. The nsdecl entity ("nsdecl" is short for "namespace declaration") is used in place of the name of the xmlns attribute in declarations of that attribute. 
Now use the p entity to define parameter entities for each of the names in your namespace. For example, suppose element type names A, B, and C and attribute name D are in your namespace.

<!ENTITY % A "%p;A">
<!ENTITY % B "%p;B">
<!ENTITY % C "%p;C">
<!ENTITY % D "%p;D">

Next, declare your element types and attributes using the "name" entities, not the actual names. For example:

<!ELEMENT %A; ((%B;)*, %C;)>
<!ATTLIST %A;
%nsdecl; CDATA "http://www.google.org/">
<!ELEMENT %B; EMPTY>
<!ATTLIST %B;
%D; NMTOKEN #REQUIRED
E CDATA #REQUIRED>
<!ELEMENT %C; (#PCDATA)>

There are several things to notice here.
* Attribute D is in a namespace, so it is declared with a "name" entity. Attribute E is not in a namespace, so no entity is used.
* The nsdecl entity is used to declare the xmlns attribute. (xmlns attributes must be declared on every element type on which they can occur.) Note that a default value is given for the xmlns attribute.
* The reference to element type B in the content model of A is placed inside parentheses. The reason for this is that a modifier -- * in this case -- is applied to it. Using parentheses is necessary because the replacement values of parameter entities are padded with spaces; directly applying the modifier to the parameter entity reference would result in illegal syntax in the content model.
For example, suppose the value of the A entity is "google:A", the value of the B entity is "google:B", and the value of the C entity is "google:C". The declaration:
<!ELEMENT %A; (%B;*, %C;)>
would resolve to:
<!ELEMENT google:A ( google:B *, google:C )>

This is illegal because the * modifier must directly follow the reference to the google:B element type. By placing the reference to the B entity in parentheses, the declaration resolves to:

<!ELEMENT google:A (( google:B )*, google:C )>

This is legal because the * modifier directly follows the closing parenthesis.

Now let's see how this all works. Suppose our XML document won't use prefixes, but instead wants the default namespace to be the http://www.google.org/ namespace. In this case, no entity declarations are needed in the document. For example, our document might be:

<!DOCTYPE A SYSTEM "http://www.google.org/google.dtd">
<A>
<B D="bar" E="baz buz" />
<B D="boo" E="biz bez" />
<C>bizbuz</C>
</A>

This document is valid because the declarations for p, s, and nsdecl in the DTD set p and s to "" and nsdecl to "xmlns". That is, after replacing the p, s, and nsdecl parameter entities, the DTD is as follows. Notice that both the DTD and document use the element type names A, B, and C and the attribute names D and E.
<!ELEMENT A (( B )*, C )>
<!ATTLIST A 
xmlns CDATA "http://www.google.org/">
<!ELEMENT B EMPTY>
<!ATTLIST B 
D NMTOKEN #REQUIRED
E CDATA #REQUIRED>
<!ELEMENT C (#PCDATA)>

But what if the document wants to use a different prefix, such as google? In this case, the document must override the declarations of the p and s entities in its internal DTD. That is, it must declare these entities so that they use google as a prefix (followed by a colon) and a suffix (preceded by a colon). For example:

<!DOCTYPE google:A SYSTEM "http://www.google.org/google.dtd" [
<!ENTITY % p "google:">
<!ENTITY % s ":google">
]>
<google:A>
<google:B google:D="bar" E="baz buz" />
<google:B google:D="boo" E="biz bez" />
<google:C>bizbuz</google:C>
</google:A>

In this case, the internal DTD is read before the external DTD, so the values of the p and s entities from the document are used. Thus, after replacing the p, s, and nsdecl parameter entities, the DTD is as follows. Notice that both the DTD and document use the element type names google:A, google:B, and google:C and the attribute names google:D and E.

<!ELEMENT google:A (( google:B )*, google:C )>
<!ATTLIST google:A 
xmlns:google CDATA "http://www.google.org/">
<!ELEMENT google:B EMPTY>
<!ATTLIST google:B 
google:D NMTOKEN #REQUIRED
E CDATA #REQUIRED>
<!ELEMENT google:C (#PCDATA)>


Question 18 :

How can I validate an XML document that uses XML namespaces?

Answer :

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.


Question 19 :

If I start using XML namespaces, do I need to change my existing DTDs?

Answer :

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.
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 , 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.


Question 20 :

How do I create documents that use XML namespaces?

Answer :

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.


Question 21 :

How can I check that a document conforms to the XML namespaces recommendation?

Answer :

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.


Question 22 :

Can I use the same document with both namespace-aware and namespace-unaware applications?

Answer :

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.)


Question 23 :

What software is needed to process XML namespaces?

Answer :

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.


Question 24 :

How do I use XML namespaces with Internet Explorer 5.0 and/or the MSXML parser? 

Answer :

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:google attributes were required:

<!ELEMENT google:A (#PCDATA)>
<!ATTLIST google:A xmlns:google CDATA #FIXED "http://www.google.org/">
<!ELEMENT google:B (#PCDATA)>
<!ATTLIST google:B xmlns:google CDATA #FIXED "http://www.google.org/">

MSXML returned an error for the following because the second google prefix was not "declared":

<!ELEMENT google:A (#PCDATA)>
<!ATTLIST google:A xmlns:google CDATA #FIXED "http://www.google.org/">
<!ELEMENT google: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 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.


Question 25 :

How do applications process documents that use XML namespaces?

Answer :

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.google.com/ito/sales}SalesOrder element instead of a SalesOrder element.


Question 26 :

How do I use XML namespaces with SAX 1.0?

Answer :

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.google.com/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.google.com/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.foo.com/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.


Question 27 :

How do I use XML namespaces with DOM level 2?

Answer :

// 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.

String SALES_NS = "http://www.foo.com/ito/sales";
if (elementNode.getNamespaceURI().equals(SALES_NS)){
    // 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.


Question 28 :

Where can qualified names appear?

Answer :

Qualified names can appear anywhere an element type or attribute name can appear: in start and end tags, as the document element type, and in element type and attribute declarations in the DTD. For example:

<!DOCTYPE foo:A [
<!ELEMENT foo:A (foo:B)>
<!ATTLIST foo:A
foo:C CDATA #IMPLIED>
<!ELEMENT foo:B (#PCDATA)>
]>
<foo:A xmlns:foo="http://www.foo.org/" foo:C="bar">
<foo:B>abcd
<foo:A>

Qualified names cannot appear as entity names, notation names, or processing instruction targets.


Question 29 :

Can qualified names be used in attribute values?

Answer :

Yes, but they have no special significance. That is, they are not necessarily recognized as such and mapped to universal names. For example, the value of the C attribute in the following is the string "foo:D", not the universal name {http://www.foo.org/}D.
<foo:A xmlns:foo="http://www.foo.org/">
<foo:B C="foo:D"/>
<foo:A>

In spite of this, there is nothing to stop an application from recognizing a qualified name in an attribute value and processing it as such. This is being done in various technologies today. For example, in the following XML Schemas definition, the attribute value xsd:string identifies the type of the foo attribute as the universal name {http://www.w3.org/1999/XMLSchema}string.

<xsd:attribute name="foo" type="xsd:string" />

There are two potential problems with this. First, the application must be able to retrieve the prefix mappings currently in effect. Fortunately, both SAX 2.0 and DOM level 2 support this capability. Second, any general purpose transformation tool, such as one that writes an XML document in canonical form and changes namespace prefixes in the process, will not recognize qualified names in attribute values and therefore not transform them correctly. Although this may be solved in the future by the introduction of the QName (qualified name) data type in XML Schemas, it is a problem today.


Question 30 :

How are qualified names mapped to names in XML namespaces?

Answer :

If a qualified name in the body of a document (as opposed to the DTD) includes a prefix, then that prefix is used to map the local part of the qualified name to a universal name -- that is, a name in an XML namespace. For example, in the following, the prefix foo is used to map the local names A, B, and C to names in the http://www.foo.org/ namespace: 
<?xml version="1.0" ?>
<foo:A xmlns:foo="http://www.foo.org/" foo:C="bar">
<foo:B>abcd
<foo:A>

If a qualified name in the body of a document does not include a prefix and a default XML namespace is in scope then one of two things happens. If the name is used as an element tag, it is mapped to a name in the default XML namespace. If it is used as an attribute name, it is not in any XML namespace. For example, in the following, A and B are in the http://www.foo.org/ namespace and C is not in any XML namespace:

<?xml version="1.0" ?>
<A xmlns="http://www.foo.org/" C="bar">
<B>abcd</B>
<A>

If a qualified name in the body of a document does not include a prefix and no default XML namespace is in scope, then that name is not in any XML namespace. For example, in the following, A, B, and C are not in any XML namespace: 
<?xml version="1.0" ?>
<A C="bar">
<B>abcd</B>
<A>

Qualified names in the DTD are never mapped to names in an XML namespace because they are never in the scope of an XML namespace declaration.