XML Interview Questions and Answers - Part 11

[VelMurugan]

XML Interview Questions and Answers

Can I use qualified names in DTDs?

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.

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

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

Yes and no.
For example, the following is legal:
<!ATTLIST google:A
bar:B CDATA #IMPLIED>

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