Can we help?
|| Home | Contact | Site map | Writings | Open source software | Français ||
We receive many visits to URIs attached to XML namespaces. Therefore we think it's useful to publish this brief discussion on XML namespaces.
XML namespaces enable developers to combine several XML vocabularies (elements and attributes), defined and used by different applications, in a single document. Indeed because the vocabularies are defined independently one from the other, there's a high risk of a name collision where an element or attribute name has different meanings to different applications.
Let's take an example: an e-commerce application may prepare an invoice in a suitable vocabulary. The invoice is next processed by a cryptographic toolkit which digitally signs it. There are now two vocabularies in the document: the invoice itself and the digital signature. The invoice is eventually processed by a routing module, which will add more tags in yet another vocabulary.
The more vocabularies, the greater the risk of collision. The three vocabulaires in this example could each define a date as a different concept (invoicing date, signing date, mailing date).
Namespaces attach an identifier to each vocabulary to remove ambiguities. Each software recognizes its own tag by their identifier.
Namespace therefore encourage software modularization.
Namespace identifiers are URIs (Uniform Resource Identifier). In practice, they will typically be URLs (Uniform Resource Locator).
The confusion arises because we expect anything that starts with http:// to be a web site address. Not so with namespaces, those are vocabulary identifiers. As the name implies, such an identifier identifies, or uniquely names, a vocabulary. It does not point to a web site.
Why use URLs (technically URIs) as identifier? Wouldn't it be simpler to come up with another mechanism?
Indeed, every universal identifier scheme (IP address, bar code, Java packages, ISBN, phone number and more) are made of two or more parts. The first part identifies the responsible party, the second part identifies a concept as defined by the responsible party. The combination of the two parts is a universal identifier.
Party identifiers must be managed by a central authority while the concept identifiers is chosen freely by the responsible party.
URLs are not build differently. There's a domain name (which identifies the responsible party) followed by a free string. The W3C took advantage of the availability of cheap domain names to construct identifiers with them. It is certainly cheaper than putting in place a new registration process.
Because we publish books and articles on XML, as well as open source software, we publish many examples of namespace identifiers built on our domain names (mostly psol.com and ananas.org).
Some readers think it is smart (or even required) to re-use our domain names to build their own identifiers. It is a very bad idea! Why? It violates the construction mechanism for identifiers and therefore it no longer guarantees the uniqueness of identifiers.
On the contrary, every application that defines an XML vocabulary must have its own unique identifier.
Use your own domain name to build your own identifiers. If you don't have a domain name yet, register one with an cheap registrar such as Gandi. If you really cannot afford even a cheap domain name, contact us to request a unique prefix identifier built on our domain. By contacting us first you ensure uniqueness.
If you browse to a URI in an XML namespaces, it is unlikely that you will find a web site. Remember, it does not identifies a web site but a vocabulary and it is not required that a web site be associated with the address.
For more information, read the W3C XML Namespace Recommendation.
If you need assistance with XML, contact us.
Last update: November 2003.