In my last column (XML-J, Vol. 1, issue 1) I talked about XML's extensibility and how it's the key to building dynamic systems. But that begs the question: Does the freedom to extend a data structure create new opportunities, or is it another example of flexibility run amok?

The debate over supporting extended or XML data structures has been taken one step further to include support of different schemas - or vocabularies. The proliferation of XML vocabularies (and sometimes competing ones) has many people worried about fragmentation. But fear not.

What to Do About All Those Vocabularies...
If XML is supposed to be the universal common language so that all systems can talk to each other, what's the deal with all these vocabularies? Doesn't that defeat the purpose?

As I see it, we're at a crossroads. The development community can take the traditional route and conclude that we must all agree on vocabularies, or it can decide that managing different vocabularies could actually be a good thing for pushing the creative boundaries of what XML can do.

As history has shown us, the well-trodden path will have a predictable outcome with most of the same winners. Certain vendors will try to co-opt the standards into the ones they decide to support and corporations will still customize them anyway. Just consider how many organizations customize EDI - and EDI is horrendously difficult to customize. Imagine what will be done with XML!

The alternative is to think somewhat orthogonally about the problem, beginning with Step One - the acceptance that vocabularies differ. Too simple? It's not a fact of life that we all have to swallow grudgingly; rather, it's an opportunity for us to use an enabling technology to do things that are truly different. Using, customizing and extending different vocabularies should be encouraged - and leveraged. In short, we should agree that we'll disagree on a single standard for XML. The trick then would be to make sure your systems are designed to handle the situation.

Technical Reasons
Let's first start with the mundane technical reasons why XML data should be customized at will. I say they're mundane because we tend to lose sight of the key benefits of XML and assume that with enough blood, sweat and tears anything is possible. As a universal data format, XML is designed to be contorted to support different schemas because:

1. It's easy: Unlike EDI, a beginner with a text editor can extend an XML data structure.
2. Apps won't break: If your app isn't interested in a new or unrecognized element, it can simply ignore it. No lost pointers, and no memory leaks - no problem.
3. Elements are identifiable: Because all elements are delimited with self-identifying tags, it's easy, for example, to parse XML data to find the "price" of the "book" even if the book has an unrecognized structure.

For these reasons applications aren't strictly dependent on a predetermined schema in order to make sense of XML data, a relaxation of the rules that opens new doors for schema and vocabulary independence. And isn't that flexibility what we've all been pushing for?

Market Forces
For all the reasons listed above, XML has found its primary residence as an enabler for today's business-to-business communication. It has been helped by the fact that EDI had already laid the foundations for the practice of handling business transactions electronically to save time and money. I think we must therefore look toward the B2B market to see how XML will be used best.

Of course, "market forces" is just a euphemism for "Money Talks," and those with big voices like to do things their own way. You can be sure there'll be many vocabularies, and customized vocabularies on top of those. The Wal-Marts of the world will likely create their own Wal-Mart-XML (for example), no matter what standards prevail. That's not a bad thing; it's what XML is made to do. The last thing we want is for an XML standard to dictate a least-common-denominator approach to business communication.

Another market force that encourages the use of many different vocabularies is the competitive pressures generated by our Internet-driven global economy. As customers' expectations of service levels continue to rise, companies no longer have the luxury of passing on the costs of inefficiencies to their customers in the form of higher prices. And since in-depth cost analysis is only a click away for many e-customers, suppliers have to fine-tune their processes like never before.

What this all means is that Wal-Mart may not always be able to rely on their favorite suppliers - the ones that were willing to adopt Wal-Mart-XML - but may need to rely on a new supplier, a mom-and-pop shop or maybe a trading hub as their business criteria vary from week to week. For this reason planning to be locked into a single vocabulary - and therefore being locked into limited partners - is to steer your enterprise toward the B2B off-ramp.

Basically, customized vocabularies are a good thing and provide a great opportunity for those companies who realize this as they integrate their e-business enterprises. Clearly the ability to be able to work with a larger number of partners - including ones not closely held - is the wave of the future. To do this in the most effective way, and if the free market has any say about it, XML must be used in a way that is vocabulary-agnostic.

Balancing Independence and Unity
In order to take advantage of the extensibility and new and emerging vocabularies of XML, it's critical to build systems that have schema flexibility built in. To properly "future-proof" your IT environment, your infrastructure must be designed to handle loosely coupled systems to preserve independence while unifying them to work toward a common goal.

Otherwise you have an architecture that requires co-opting any system, application or device it connects to. The last thing you want to do is place barriers-to-entry in front of partners who could possibly benefit your business. If you can eliminate the coercion from e-commerce, fragmentation becomes a nonissue.