To be clear, I do believe that XML is a viable option for trading data electronically, in fact, any type of data can be considered EDI, if you look at the definition of EDI as "the structured transmission of data between organizations by electronic means" (Wikipedia). My point back then was that companies were leaning toward XML as the only option for their trading partners to trade electronically, and for some, that decision was based on the fact that traditional EDI was going to be phased out over time and replaced with XML.

Certainly EDI has been around quite awhile now, and XML has been around long enough that standards have been created and is coming to its own. There are many new software packages or releases of existing packages that have XML as the basis for supporting the data, so XML is definitely not going away, but I do think that EDI data has its place as well. I'm not sure if it is well published, but many of these same software packages now also have incorporated an EDI model into the tools to support either EDI or XML as a data feed. My point being that there is a place for both the EDI and the XML standards as methods of exchanging data between partners. What's more important is that all parties should then support both options rather than just one or the other.

I reported in an article last year that the Music Industry had decided to create a standard of XML for their industry, and over the year I've seen other industries begin to adopt their own standards or create standard usage of XML as well. This is a kin to the movement of Grocery and Apparel Retail creating a subset of EDI standards such as UCS and VICS from the base X12 standards. Unfortunately that means more standards to be supported thus making it harder to manage between partners.

When EDI was adopted by the larger retailers, X12 standards were used and an electronic Purchase Order (850) and Invoice (810) were created and at same time or shortly after, the Grocery industry created the UCS Standards. Unfortunately they also created new Business Transactions. (i.e. Grocery Purchase Order = 875 and Grocery Invoice = 880). That probably made sense when the Grocery Retailers were only planning to trade electronically with their larger partners and these partners were primarily food related. However as their electronic trading started to expand so that they could further penetrate deeper into their partner relationships, they came to realize that Base X12 EDI documents were being used verses the UCS standards they were expecting,  specifically with hardgood products. The good news is that the Grocery Retailers have realized that their assumptions were off a bit, and have now implemented the use of the more general EDI business documents. They now support both 875 and 850 Purchase Orders and 810 and 880 Invoices. My concern on behalf of the usage of XML is that different Industries will create their own standards and will not be cross functional with other industries.  

I certainly recommend that whatever electronic trading that can be done, should be done and often; however make sure that you are collaborating with a larger mix of partners to establish your electronic Trading policy. And while doing so, keep in mind that there needs to be a place for both traditional EDI as well as the up and coming XML data formats. Allow your partners to support what they've build within their infrastructure and with other partners. Developing a "Best Practice" with your partners around electronic trading is good for everyone.