Mile High XML BannerMile High XML HomeAboutInteresting PapersLinks Dave's Personal Page

XML Namespaces

Dave Hollander

November, 1999



Introduction

In January 1999, Namespaces in XML[1]became a W3C Recommendation. "Recommendation", the final step in the W3C process, means that the document is done, frozen, agreed-upon and official. While namespaces have not yet been broadly used in eCommerce, work-in-progress at the W3C, CommerceNet and elsewhere should change this.

The Namespaces specifications were revised December 2002 Namespaces in XML 1.1

This report will look at how namespaces work and how XML Schemas and Packaging resolve issues which is likely to result in a considerable increase in the use of namespaces in XML based eCommerce in the year 2000.


Problem at a Glance

Namespaces are a simple and straightforward way to distinguish names of elements in XML documents. From an XML view, this is all that they do. However, for implementers of agile and adaptable eCommerce systems, namespaces provide a means to develop more flexible and easily maintained applications.

To illustrate this, consider a typical purchase order. A purchase order contains information targeted for many different groups, including logistics, procurement and financial. XML, as typically used today, exchanges information between these groups in a document pre-designed to contain all of the information needed by each group taking part in the transaction. Each group develops tools that validate[2] the entire document and then select and manipulate the data specific to their function. This type of XML application can provide significant advantages when compared to custom integrated applications.

Namespaces can improve the adaptability of the described XML application. Consider how each group must change their system if one group's information needs change. For example, if one group is replaced by a different group that uses different information then the must change. All of the groups must agree on a new document type then modify their systems to accept the new document.

With a namespace aware application that uses XML Schemas, the changes can be confined to only the groups that need to provide the new or different applications. All other applications can continue to work with their existing tools. Additionally, only the effected parties need to agree on the structure of the new data. Logistics need not participate in or even be aware of changes to the financial section of the document. Additionally, namespaces also makes it easy use information types from well-known libraries.

The best way to understand namespaces is by example. The first example will examine the basics of namespaces and the second will describe some advanced features. Finally, both the issues and solutions to using namespaces in eCommerce applications are described.

Example 1: Basic Namespace Anatomy

Consider a company that already uses XML for purchase orders but now wants to add information that will be used in placing the order via OBI.

With Namespaces:
<purchase_order xmlns:obi="www.obi.org">
	<obi:part_number>4444-54321A</obi:part_number>
	<part_number>54321-XYZ</part_number>
	_
</purchase_order>

The namespace , , declares that the prefix will be assigned to represent the www.obi.org namespace. The element identifier, is a in the in the OBI namespace. The other is considered in the namespace.

To use namespaces, you need only to add two types of information to your XML documents.

Example 2: Additional Features

The recommendation defines additional features to make namespaces more useful, practical and perhaps less ugly. These features include prefixes on attributes, namespace scoping and a default namespace that allows us to leave some namespace prefixes off elements.

Building on the earlier example, let's see how these features work.

<purchase_order xmlns="www.commerce.net"  xmlns:obi="www.obi.org">

	<!-- this is commerce.net namespace -->
	<requester obi:id="aabbcc">
		<name>Dave</name>
		<title>Director of eCommerce Knowledge 
			Management and Interoperability</title>
	</requester>

	<!-- CommerceNet part number -->
	<part_number>CN-1123</part_number> 

	<obi:purchase_order>
		<!-- Scope rules declare that all un-prefixed elements 
				are now part of the OBI namespace. -->
		<part_number>4444-54321A </part_number> 
		<obi:description xmlns="www.w3c.org/HTML/1998/html4">
		<!-- Now, the default namespace is defined to be html4 -->
		<title>My Product</title> <!-- an html title -->
		<h1>This is big bold text about my product</h1>
		<p>This is a <I>paragraph</I> that 
		describes my product.</p>
		</obi:description>
	</obi:purchase_order>
</purchase_order>

The scoping and defaulting rules are used here to omit large numbers of namespace prefixes from the document. For example, the description sets the default namespace to allow HTML markup directly in the purchase order. If the HTML had to have prefixes, each element would have to be modified when copied into or out of the document onto a web page. It would also be harder to read and understand the description.

That is all there is to the syntax of Namespaces in XML. For more detail and examples on how namespace mechanics work, see the recommendation or Tim Bray's excellent paper on XML.COM[3].


Issues Using Namespaces

Namespaces are crucial for the future of XML programming. However, eCommerce applications must overcome two significant issues that their use creates; documents with namespaces are difficult to validate using DTDs and deciding what a namespace URIs should resolve to.

DTD based XML validation tools rely on having each and every element in a document defined in single DTD. It is possible to create a DTD that declares each element from the default and included namespaces. However, in doing so you loose the advantage of isolating changes in one part of the document from the other sections.

The W3C XML Schema Working Group is addressing validation of namespace rich documents. The group's requirements[4] include defining how documents that are composed of information drawn from multiple namespaces are to be validated. The schema language further assumes that the schemas governing each namespace may be developed and maintained separately.

In our example, namespaces and XML Schemas allows the developer of the revised purchase order can simply state that the OBI section of the document is to be validated according to the OBI schema. The developer of an application that only uses OBI data can simply validate the document according to the OBI schema and tell the application to only use data from the OBI namespace. They do not need to change their system no matter how much the rest of the document changes.


What do namespaces point to?

What the URI reference of a namespace declaration points at is the most controversial and misunderstood aspect of Namespaces in XML. For some people it is even more confusing because it is perfectly legal to use an URL for the URI reference. It is natural to expect a URL like http://www.commerce.net to point to something meaningful like a DTD.

The namespace specification does not require or even suggest that a URI/URL should resolve to anything. The W3C chose URIs because they contain domain names (www.commerce.net) which are managed globally across the Internet. It is completely legal to use an URL that points to a web document that does not exist.

The result is confusion about how to find information about the namespace being used. Many believe the namespace URL should point to a DTD or schema, while others believe it should resolve to a style sheet or descriptive document. This lack of consensus has slowed the adoption of namespaces.

The members of the XML Activity understand this limitation. Not only are XML Schemas establishing how to locate a schema, a work group is starting up a packaging activity to define a standard means to have one URI describe the many different documents needed to fully describe a namespace. These documents include schema(s), stylesheet(s) and documentation. It seems reasonable to believe that this will become the appropriate target for a namespace URI.


Conclusion

Namespaces in XML, when used with the emerging XML Schemas and XML Packaging specifications can make eCommerce XML applications easier to develop and maintain. They will certainly be used in many of the applications developed in the year 2000.

Future reports will keep you informed of advances and conventions for the use of namespaces. CommerceNet will work with the XML development community to assure that these efforts meet the needs of an agile eCommerce company.




References

  • [1] Namespaces in XML, W3C Recommendation by Tim Bray, Dave Hollander, Andrew Layman Published on 1999-01-14.

  • [2] XML Schemas in eCommerce by Arofan Gregory and Dave Hollander Published on 1999-10-01.

  • [3] XML Namespaces by Example by Tim Bray in XML.COM.

  • [4] XML Schema Requirements, W3C Note; by Ashok Malhotra and Murray Maloney Published on 1999-02-15.


  • Last Modified: December 18, 2002
    Dave's Personal Page mhxml.com