This article explores the paradox that sharing a common vocabulary can actually restrict the richness and nuances of a business paradigm.

The Trend to Share Common Vocabularies
One of the trends we find in the rapidly expanding world of XML is a desire to define unified vocabularies for expressing exchanged data. It seems obvious that the number of XML vocabularies used should be minimized, and, indeed, efforts to find agreement within various industries are laudable and to be encouraged. But these efforts may not always reduce the difficulty of exchanging information and might, paradoxically, limit the longevity of information by hiding complexities behind superficial agreements. The issue is meaning, not markup.

Consider this illustration. At a summit of religious leaders aimed at increasing common understanding among the world's religions, it is decided that everyone will speak English and use the vocabulary of Protestant Christianity. However, as soon as the discussions start, there are problems. Someone uses the word heaven and many people nod in recognition. But as the discussion progresses, it is clear that even the different Christian delegates have understood different nuances of the word, to say nothing of the Hindu and Buddhist representatives. As time goes by, they realize that perhaps they should have agreed at the start not to use a single vocabulary but rather to describe what the relationships were between the apparently similar words in the vocabularies with which they were already familiar.

In the same way, a shared vocabulary for users in the same domain may not be enough to allow them anything but the most rudimentary sharing of information. Different organizations usually have diverse backgrounds and varying views of the world, and their competitive advantages often result from their different paradigms. When all that is involved is basic data (to do with billing or ordering, for example), the issues may be trivial, but full-scale cooperation between companies will increasingly involve mind-to-mind connections. At this point, when differences come to light they will result from trying to cram paradigmatic variations into the same syntax. Resolving differences will be hard even when the difference has been detected because the semantic strength of the vocabulary in use may not allow for the proper expression of the alternate paradigm.

The Paradox
So we discover a paradox. It would seem that common purposes should share common vocabularies. Yet in defining the data model for a business, it may be better to invent a local variant of an existing vocabulary - or in extreme cases a whole new vocabulary - to fully express the richness and nuances of a business model and paradigm. This was, after all, the feature of XML that first drew the attention of both the publishing and the computing worlds - that magical letter X for eXtensible. The chief skills for the use of XML will prove to be those of the business analyst, defining data and naming parts, rather than those of the programmer.

The Need to Map the Relationships Between Paradigms
Translation will therefore be key. There is certain to be a need to move between different vocabularies, be they supersets of standards or custom vocabularies. In these early days of XML it will no doubt be enough to use straightforward transliteration functions. The functions of the proposed XSL standards are more than enough to allow exchange between basic business vocabularies. If the number of these vocabularies can be kept to a minimum, the task of setting up the simplest transactions could be easy, especially using visual tools to perform the mapping. But there will always be a mapping, even if there is only one common exchange vocabulary. The mapping describes the relationship between the meanings of two paradigms, and will be easiest to create if the paradigms in question are mapped and understood. Paradoxically, two different paradigms attempting to use a common vocabulary may produce more confusion and difficulty than if they had used custom vocabularies, because their paradigmatic differences may be concealed in the use of common terms.

But mechanical transliteration is not the same as translation. Translation involves the expression of the ideas within one paradigm in the language of another, and to translate mechanically is very hard. Defining a true translation mapping may involve different treatment of the same tags in different contexts and requires an understanding of both paradigms. As the need to connect heart to heart between e-businesses increases, there will be more and more demand for comprehensive approaches to creating XML mappings.

To connect from the heart of my e-business to the heart of yours would be impossibly expensive in shared systems without XML, but even with it the system analysis needed to create the translation is a significant task. We should not assume that XML is a panacea, or that the standardization of vocabularies will automatically bring interoperability. XML provides us with a medium to express our understanding of the meaning of data, but we will still have to first discern realities and differences of meanings when we exchange data.

What Matters Is the Meaning
May the efforts of industry groups to define common XML vocabularies flourish and succeed! But should they fail to reach a single, uniform set in every case, if diversity should multiply, no problem. At least the meanings will have been well described, fully annotated and put within reach of analysis, mapping and machine manipulation. What matters is the meaning, not the markup.