Menu

Myth #6: An XML namespace has an internal structure

Table of Contents

There are a number of origins of this myth:

  • The definition of an XML namespace states that it is a "collection of names" that "has internal structure."
  • Appendix A, which is non-normative, describes a possible structure for XML namespaces.
  • The idea that an XML namespace is an object (it is not—see myth #3) leads directly to questions about its member elements, which are organized within its structure.
  • Structure is one way to resolve the problem that a universal name does not identify a particular element type or attribute unless it is known beforehand whether the name applies to an element type or attribute (see myth #2).
  • Validity imposes a set of traditional namespaces on an XML document. It is therefore tempting to think that the structure of an XML namespace will mimic or approximate this structure.

As was shown in myth #1, there is no reason for XML namespaces (as opposed to XML namespace URIs) to even exist. Thus, their structure is unimportant—it is never used in practice—and it is unfortunate that it is ever discussed. Nevertheless, it is interesting to explore the possible structures of an XML namespace, if only to satisfy the curiosity needlessly raised by the recommendation.

In discussing possible structures, it is necessary to note that:

  • The structure proposed in Appendix A is non-normative and therefore only one possible structure, not the structure.

  • Inherent in the notion of structure is the idea that an XML namespace has certain name-related capabilities, such as the ability to determine whether a particular name applies to an element type or attribute. For example, keeping element type names separate from attribute names implies the ability to distinguish between these. Except for specifying that a particular element type or attribute name is in a particular XML namespace, the XML namespaces recommendation does not require or specify such capabilities.

  • The names stored in an XML namespace are local names. Attempts to circumvent the need for structure by storing other forms of names, such as universal names, are simply adding structure by other means.

And now, on with the show. Here are five possible internal structures for an XML namespace:

  1. A set. Although the normative part of the XML namespaces recommendation states that an XML namespace "is a collection of names" and "is not, mathematically speaking, a set," there is nothing other than the latter statement that prevents it from being a set. In particular, the recommendation describes how to map names in an XML document to XML namespaces—in other words, to specify their membership in an XML namespace. Because the recommendation does not specify any other behaviors, a set is sufficient to represent an XML namespace. There are two obvious drawbacks to this structure. First, it does not provide enough information to support most name-related capabilities, including determining whether a name applies to an element type, an attribute, or both. Second, it cannot contain unprefixed attribute names (see myth #4), as these cannot be distinguished from the local part of universal names.

  2. Two traditional namespaces—one for element type names and one for prefixed attribute names. In some senses, this is the minimal "intelligent" structure of an XML namespace, although the lack of unprefixed attribute names means that the namespace lacks a number of interesting name-related capabilities.

  3. The structure in Appendix A. This structure consists of one traditional namespace for element type names, one traditional namespace for global (prefixed) attribute names (see myth #5), and, for each element type, one traditional namespace for unprefixed attribute names. It provides the most complete name-related capabilities and (not surprisingly), except for the traditional namespace for global attributes, matches the structure of traditional namespaces imposed on an XML document by validity.

  4. Similar to (3), but without special treatment of global attributes. Thus, rather than having a single traditional namespace for global attribute names, each element type has two traditional namespaces for attribute names: one for prefixed names and one for unprefixed names. This structure assumes that the type and semantics of global attributes can vary depending on the element type they are associated with. While this is allowable under the XML 1.0 recommendation, it defeats the purpose of being able to assign universal names to attributes (see myth #5) and is probably best ignored.

  5. Same as (4), but without per-element type traditional namespaces for unprefixed attribute names. This structure takes an even more pessimistic view than that in (4), assuming that unprefixed attribute names are not in an XML namespace (see myth #4). Like (4), it is best ignored.

As can be seen, the structure of an XML namespace has many possible forms, depending on what is trying to be achieved. What is important to remember is that all of these forms are irrelevant to the actual use of universal names, which are the sole purpose of XML namespaces.

Myth #7: There is a "null" XML namespace that contains all element type and attribute names not declared to be in a specific XML namespace

There are two probable origins of this myth. The first is again a wish for completeness—that all element type and attribute names are in some XML namespace. The second is that some namespace-aware applications use a null or empty (zero-length) URI to process names that are not specifically declared to be in an XML namespace. For example:

   if (uri == null)
   {
      // Process names not in any XML namespace
   }
   else if (uri.equals("http://www.foo.org/")
   {
      // Process names in http://www.foo.org namespace
   }
   else if (uri.equals("http://www.bar.org/")
   {
      // Process names in http://www.bar.org namespace
   }

In fact, a "null" XML namespace does not exist and the use of null or empty URIs in applications is an implementation detail. The reason is that, if such a namespace did exist, its names could be mapped to more than one element type or attribute, each of which has different types and semantics. Such names are not universal and violate the requirement that "...document constructs [element types or attributes] should have universal names, whose scope extends beyond their containing document."

Myth #8: XML namespaces are strongly related to schemas

Because XML namespaces contain element type and attribute names and schemas contain element type and attribute definitions, there is a strong temptation to think that there is a special relation between the two. In fact, the relationship between the set of names in an XML namespace and the set of names in a schema cannot be predicted any more than it can for any two other sets picked at random. That is, all of the following are possible:

  • The names in the XML namespace are the same as the names in the schema. This is generally the case for schemas defined today.

  • The names in the XML namespace are a strict subset of the names in the schema. This will be a common case in the future, when schemas are built in modular fashion from other schemas. In this case, the schema draws its names from more than one XML namespace.

  • The names in the XML namespace intersect, but are not a subset of, the names in the schema. This will also be a common case in the future, in which only part of one schema is used to build another schema. Again, the schema draws its names from more than one XML namespace.

  • The names in the XML namespace do not intersect the names in the schema. This is a trivial case and is mentioned only for completeness.

Myth #9: The XML namespaces recommendation redefines validity

Because the XML namespaces recommendation defines how to construct universal element type and attribute names, and because validity has rules concerning names (no two element types may have the same name, no two attributes of the same element type may have the same name, and so on), it is reasonable to assume that the XML namespaces recommendation redefines validity in terms of universal names. For example, no two element types may have the same universal name and no two element types whose names are not in an XML namespace may have the same name; no two attributes of the same element type may have the same universal name or the same unprefixed name; and so on.

In fact, the XML namespaces recommendation does not mention validity at all. The reason for this is most likely that there is no way to declare an XML namespace in a DTD; hence, there is no way to discuss universal names in DTDs, a necessary prerequisite to redefining validity in terms of universal names.

Furthermore, it is possible to create documents using XML namespaces that many people would think are valid (and which are certainly valid in spirit) but which are not valid as validity is defined in the XML 1.0 recommendation. For example, the following is not valid because the root element type (A) does not match the document element type (foo:A) in spite of the fact that both could reasonably be interpreted to be the same element type ({http://www.foo.org/}A).

 
   <!DOCTYPE foo:A [
      <!ELEMENT foo:A EMPTY>
      <!ATTLIST foo:A
                xmlns CDATA #FIXED "http://www.foo.org/"
                xmlns:foo CDATA #FIXED "http://www.foo.org/">
   ]>
   <A/>

Because of this, it is likely that at some point in the future validity constraints on element type and attribute names will be redefined in terms of universal names. (They are currently defined in terms of qualified names.) When and if this will happen is not known, although a reasonable time would be in conjunction with XML Schemas, as these circumvent the problems of declaring XML namespaces (and thus universal names) in a DTD. In the meantime, it seems safe to say that any schema-driven software that interprets validity today in terms of universal names instead of qualified names is unlikely to meet much resistance from the XML community.

Myth #10: XML namespaces are related to the traditional namespaces required by validity

This myth is both a myth and not a myth. At a conceptual level it has some validity. Although it is never stated in the XML namespaces recommendation, XML namespaces can be thought of as partitioning the traditional namespace for element type names into multiple traditional namespaces—one for each XML namespace, plus an additional traditional namespace for element type names not in any XML namespace. Similarly, XML namespaces can be thought of as partitioning the per-element type traditional namespaces for attributes: one traditional namespace for each XML namespace, plus an additional traditional namespace for unprefixed attribute names.

(One consequence of partitioning the per-element type traditional namespaces for attributes is that a global attribute name can appear in more than one traditional namespace—in particular, it appears once for each element type on which it occurs. Although this appears to reduce the globalness of global attribute names, it is needed to enforce a namespace-aware definition of validity, which requires that no two attribute names have the same universal name or the same unprefixed name. For more information, see myths #5 and #9.)

On a technical level, the myth is a myth: the XML namespaces used by an XML document are not related to the traditional namespaces used by that document. In particular, the names in the XML namespaces are different from those in the traditional namespaces and cannot be directly compared. For example, consider the name of the type of the following element:

   <foo:A xmlns:foo="http://www.foo.org/">

In the traditional namespace for element type names, the name of this element type is foo:A; this is because the traditional namespace does not recognize foo as a prefix identifying an XML namespace and process it accordingly. In the http://www.foo.org/ namespace, the name of this element type is A; its corresponding universal name is {http://www.foo.org/}A. Both names are different from foo:A.

Because the names are different, you should be very careful about how you use XML namespaces if you expect your document to be used by both namespace-aware and namespace-unaware applications. For example, the following elements have the same element type name according to a namespace-aware application and different names according to a namespace-unaware application; similar difficulties arise when using default XML namespaces.

   <foo:A xmlns:foo="http://www.foo.org/">123.45.67.8</foo:A>

   <bar:A xmlns:bar="http://www.foo.org/">123.45.67.8</bar:A>

Myth #11: XML namespaces are part of XML 1.0

The XML 1.0 recommendation specifically warns users against using colons in names, stating that these are likely to be used in the future for XML namespaces. In spite of this, XML namespaces are a technology layered on top of XML 1.0, not part of XML 1.0.

This has several consequences. First, XML 1.0 documents are not required to use XML namespaces and XML 1.0 parsers and applications are not required to recognize or process them. Second, some early XML technologies, such as SAX and the DOM, do not directly support XML namespaces because they were developed before XML namespaces were developed. Third, DTDs do not directly support XML namespaces and concepts such as validity are not defined with respect to XML namespaces.

Fortunately, XML 1.0 was designed with XML namespaces in mind. In particular, element type and attribute names can contain colons specifically so that colons can be used to separate an XML namespace prefix from a local name. Thus, a name such as foo:Bar is a legal name in XML 1.0 and can be processed by namespace-unaware software. Such software simply doesn't recognize foo as an XML namespace prefix; instead, it treats it, along with the colon, as part of the name.