This freedom however comes with an inherent problem attached. Different people work with different domains, but the phraseology used can often be common. For instance:
And when they exchange or agglomerate information, there is always the danger of being unable to determine which meaning to use, or even worse using the wrong meaning.
The same is the problem with XML documents. The tags used to markup one document may conflict with the tags used to markup another. This can lead to ambiguity when these documents have to be used together in a common process as a single source of information.
Consider the following two documents:
Note that the main element <member> and all its constituent characteristics such as <name>, <color> etc are the same in both boxes. But at one glance we know that they are describing two very different entities and the meanings are very different as well. For instance, in the first case <number> refers to the registration number of Jonathan, a human, but in the second case <number> refers to the atomic number of Sodium, a chemical element.
This example might be relatively trivial since we would rarely want to process human and chemical information together as a single source. However, there could be more tricky instances. Imagine two humans are being described and perhaps their “weights” are being documented. In one case the weight might be the persons own weight but in another case it might be the maximum weight that one is capable of lifting (for a weightlifter perhaps). Aha… now there is a more insidious problem here!
This is essential that there be no ambiguity in describing an element or its attributes
What solutions can we have to this?
This solution takes the simple way out. Use only specific and unambiguous names to describe the parts of a document. So, don’t call it weight>, instead call it human-weight> and atomic-weight>. Ekes… that is restrictive!! Moreover, how would one know if a particular name has not already been taken.
This solution is the same as the above but it does away with the problem of not knowing if a name has been taken. Just publish all the names with a central registry! But that is really immense and unrealistic. Also it is still very restrictive – after all one would still like to use the simplest and nicest name and not be denied it, simply because someone else got there first.
This is the solution that we will discuss in more detail. It does use the concept of specific names but makes the names specific in an elegant way and does not need to use a separate central registry (actually it rides on an existing one). This is called the Namespace definition.
As we have seen in Solution 1, we could use the terms human-weight> and atomic-weight> to distinguish between the two “weight” terms. In a way, this is the use of a prefix to make the scope of the term called “weight” narrower.
Namespaces similarly provide for scoping using prefixes for the tag names, but it goes one step ahead by also specifying a formal syntax for doing so. The syntax is: <prefix:tagname> i.e. “ prefix” followed by “colon” followed by “<tagname>” Thus in our example, the prefix-ed tags would be: <human:weight> and <atomic:weight>
Prefixes solve part of the problem but the solution is not yet complete- reason being that the prefixes that one might use themselves could be conflicting. That is to say, nothing prevents you and me from both using the same prefix.
So we have a perpetual problem that we have to solve by providing something unique which a prefix refers to and which is globally acceptable and accessible. This is the Uniform Resource Identifier or URI.
Consider the following example:
Notice here in the line marked in red, that the prefix “human” has been associated with a URI (in this case a URL or Uniform Resource Locator) called http://www.humancolony.com/2004/human (don’t click on this – I am not responsible for what might happen!!!). And as you might be aware, internet URLs are unique so the likelihood of conflicting prefixes is automatically reduced to nil.
So, if you want to author an XML document, and you want to make sure that no one else conflicts with your terminology, use namespace prefixes and associate the prefix with your very own domain URL.
One is not restricted to the use of a single namespace. One can use one default namespace and multiple additional namespaces in an XML document and its elements.
Consider the following variation of our “human”:
In the above example, the default namespace is http://www.humancolony.com/2004 since it defines no prefix. The additional namespace which associates with the prefix “human” is “http://www.humancolony.com/2004/human”. Consequently, all elements except the date-of-birth element <dob> are from the namespace prefixed as “human”. <dob>, on the contrary has no prefix and therefore derives from the default namespace.
Finally, a short note on namespace scoping will be in place. An XML namespace’s scope is quite simply all the elements and attributes within the namespace definition. Simple as that? Well yes, it is!!
We have now gone through the concepts of unambiguous naming and XML namespaces (though we will return to these topics as part of later chapters as well). For a more complete and formal discussion on XML namespaces, please refer to the following site: http://www.w3.org/TR/REC-xml-names/ as well. Now, move on to a relatively more practical aspect of XML - visualizing and working with it. We will introduce some tools and methods to view, edit and manipulate XML documents.