XML Namespaces

This section discusses XML Namespaces, a method of resolving conflicts between similar tagnames having separate meanings. Also a choice between the use of namespaces and the ebXML context mechanism is discussed.

Working

When designing an XML schema, many designers re-use other schemas. It is quite common to use a subset of HTML when you need a piece of formatted text somewhere in your XML files. But, when using elements from multiple sources (read: XML schemas), you need to distinguish between the elements. <title> can be the title of a chapter or the title of a person. When one tag exists in multiple schemas, you need a way of telling them apart.

XML's way of telling tags apart is to add a namespace reference in front of the tags. A namespace reference is a string added in front of the tagname, separated by a colon. The definition of that namespace reference has to be done beforehand, linking the reference (in itself just a string) with the intended XML schema. See Example A-9

Example A-9. Example use of namespaces to distinguish between two title tags, one indicating a chapter's title, the other indicating a person's title.

	    <doc:chapter xmlns:doc='http://docdoc.com'
	      xmlns:titles="http://title_references.net">
	    <doc:title>Title of chapter</doc:title>
	    <doc:para>
	      This is a sample paragraph about 
	    <titles:title>Prof. Dr.</titles:title> Broadsword
	      demonstrating namespaces.
	    </doc:para>
	    </doc:chapter>
	      
	    

There are more possibilities, for example defining a default namespace for all unspecified tags within a tag (handy when including HTML for documentation). But above example covers the basics.

Design decisions involving namespaces

The mentioned example of including some HTML markup within an XML document is one of the normal uses of namespaces. It can, however, also be used to glue together different classifications or different models. ceXML could define a set of general tags (including addressing etc.), which can be complemented by allowing tags from, say, a prefab concrete namespace. This can be used as an alternative to ebXML's context mechanism (see the section called ebXML's context mechanism in Chapter 5).

Using namespaces results in an XML-only solution, which can be readily used by everyone. The context mechanism needs a purpose-build software solution to accompany it. But the context mechanism is more flexible and it can generate schemas without any need for action on the client side.

The namespace mechanism has been devised to tell apart tags with the same name but a different meaning. The context mechanism has been devised to construct a set of tags applicable to a certain intersection of contexts. As the intended usage of ceXML is to communicate about building and construction data, it is likely that one has to deal with a number of different classification systems and models. This means that it will be difficult to assemble the right set of tags, excluding the namespace mechanism for that task.

Conclusions

Namespaces can be useful, but their use is limited. For the detailed assembling of the right set of tags for communicating a about a specific building or construction, the context mechanism is best suited. For separating included documentation (probably in an HTML-like format), the actual tags containing the construction data and the generic addressing-like tags, the namespace mechanism is the best method to prohibit possible tagname conflicts.