At the end of the ’90s it was becoming clear that EDI, the text formats (comma-separated value files, for example) and binary formats that were widely used in all industry verticals lacked a number of important characteristics: they weren’t (easily) human readable; they required dedicated parsers for each version or sub-version or dialect or interpretation of the format; and, probably most important, they weren’t easily extensible. Those are some of the reasons that led to the creation of XML (eXtensible Markup Language).

XML is human-readable; no matter what the XML structure is, a single standard parser can process it; XML is meant to be easy to extend (after all, that’s what the “X” stands for!). Yes, XML is much more verbose than other ways of exchanging information, but hardware and bandwidth made a lot of progress by the late ’90s, and IT professionals were willing to trade the cost of dealing with larger messages for the benefits that doing so brings to the table.

How Things Are
Fast forward several years. You might expect that all B2B infrastructures have switched to XML; all information among companies is exchanged as XML under the control of standard XML Schemas that enforced the validity of every XML message moved on the wire. Developers need only focus on dealing with the XML data model in their applications and integrating new business partners in the B2B infrastructure is a breeze.

Well, reality is very different. It’s true that XML has become the major standard for exchanging information in B2B infrastructures in most industry verticals; it’s true that XML has replaced the prominent role of EDI formats or proprietary text or binary formats in doing so. However, it’s surely not true that the use of non-XML formats in B2B contexts has disappeared: in many contexts EDI is still the most adopted way to exchange information (think about SWIFT); in some other cases, standard bodies provide both EDI and XML formats for their own specifications (think about IATA or HL7), and your organization may end up being in the situation where it’s dealing both with vendors that are still using EDI formats and with others that have switched to XML. To make things even more complicated, services on B2B infrastructures are usually developed using languages like Java or C#, which create yet another level of indirection with the data model that has to be used for information to be exchanged (XML, in the lucky cases) or even stored (tables).

There’s Hope
In the past few years the XML community has tried to find a remedy for this situation. So-called native XML languages have been introduced at least to make it easier for IT organizations to deal with XML structures, eliminating the need for bridging between the XML and the Java or C# data models whenever you had to deal with or create XML documents. First XSLT and then XQuery have provided a big help in that direction. Even the more recent LINQ-for-XML approach introduced by Microsoft moves in the same direction. Both XQuery and XSLT are languages that are designed to work against the XML Data Model (XDM); when developers write XQuery or XSLT, the only data model they’re dealing with (to access/query it or create it) is XML. The most obvious reaction that IT organizations may have is that neither XQuery nor XSLT are well suited to dealing with a set of different data sources, like XML messages, EDI messages, or text or binary formats.

If you think about it carefully, what XQuery and XSLT really require is for the data they’re working on to look like XML; the data must be available as an XML Data Model; it doesn’t really matter what the underlying physical representation of such data is as long as XQuery or XSLT can see it as XML. Considering that XML provides a highly flexible way to represent information, it’s definitely possible to think about a variety of ways in which the data contained in an EDI message, for example, can be interpreted as XML. That’s an intriguing concept: provide a way to access or create EDI messages as XML, and my B2B infrastructure can be designed to just deal with XML – there’s no need to have special cases meant to support business partners that are dealing with EDI or even proprietary text or binary-based formats.