XML is now officially five years old and has gone from being an obscure curiosity to becoming the primary vehicle for describing things in the computer world. An XML "document" is a description of something, using HTML-like tags to indicate the attributes (such as a customer's name) and containment characteristics (a collection of line items) of the thing being described. XML itself is the grammar used for writing these descriptions, and the specific rules for defining a specific object's tags are collectively called a schema. By design, the primary language for defining schemas is itself an XML language called, not surprisingly, the XML Schema Definition language (or XSD). A schema is a relatively easy piece of code to write, especially with tools such as Stylus Studio by Progress Software (formerly eXcelon), XMetal by Corel (formerly SoftQuad), or the open source oXygen by syncRO (not yet bought out by anyone, but give it time). In many cases, such tools will actually let their users load an XML document and then take a best guess as to what the likely structure is supposed to be based upon what's in the document itself. Therein lies a dilemma. Other issues crop up when XML is in routine use What is an invoice? XML was supposed to give a good answer to this kind of question, that would allow common descriptions of such objects. Like so many other things, it turns out not to be so simple. If you take a look at the vast number of different XML formats being used to describe something as intuitively simple as an invoice form, you can see one of the problems that is now beginning to crop up in many companies -- namely, that everyone has a different idea of what makes up an invoice, a purchase order, an employee form, or any of the thousands of business "objects" that cross the boundaries between programming and commerce. To help you better manage this process, I'll take a look at how to develop a good strategy for schema management and what to look for in someone who is going to manage schemas The problem of too many choices As the process to create schemas from XML sources becomes simpler, the tendency among programmers and application designers is to custom-build a schema that meets an immediate need. Typically, most developers try to coordinate their actions within their immediate work group, but in larger companies, they may not necessarily be aware of parallel work being done by developers in a different part of the company, or they may not be aware of already existing schema definitions. Eventually the applications get written and deployed, and then the sinking realisation is made that there are two different applications using two incompatible versions of the same (or overlapping) objects. As Web services architectures become more pervasively deployed in intradepartmental applications, which seem to be where the Web services wave is currently strongest, this kind of scenario will occur more and more often. The problem is even worse than it may appear on the surface, because there are often times when two schemas describe overlapping parts of a specific business process or transaction, so it is often not just a case of sending out a memo asking whether someone has developed an invoice schema. In the language of programmers, the company namespace has become compromised. XML schema manager--the gatekeeper Most IT departments currently have a database administrator (DBA). The role of this person differs from that of a developer; the administrator acts as a gatekeeper to ensure that the database stores retain their integrity. Thus, the DBA often has to act as a referee to ensure that database programmers aren't creating unnecessary (and potentially divisive) tables, to determine which stored procedures do not have the potential of corrupting the databases, and to ensure that only authorised people can get access to the database. Within the industry, an XML counterpart to the DBA is emerging, and it's called an XML schema manager, or XSM. The principle role of an XSM is part librarian, part referee, and part researcher. The XSM is responsible for the repository of XML schemas that a company generates. Whenever a particular schema needs to be incorporated into an application, the schema manager should approve the use of that schema or suggest alternatives and should try to limit or eliminate those schemas that already duplicate at least some existing functionality.