|
From: EDI Purist Subject: The Future Direction of EDI I have been following the discussion of XML with some interest and see where there might be an interesting application for WEB-based data entry. I am somewhat more of a purist when it comes to EDI and have concentrated solely on the creation and transmission of X12 transactions in a more traditional way. As such, I an in no position to criticize or applaud your efforts in this area of electronic business. |
|
Dear EDI Purist, We understand where you are coming from whole heartily. Many of our members have a strong EDI background also. It is from this viewpoint where the initial XML/EDI concepts came into existence - to solve problems where our systems were hitting up against a wall. What we found, was that after we addressed our EDI problems, XML/EDI had a scope much larger than just EDI. First let us ask you this question as food for thought - If X12 or UN/EDIFACT adopted the use of XML as delimiters for transactions would then a definition of purist extend to include XML/EDI messages also? Because, if we take workflow, document management, search and retrieval; business processes in general, out of the equation - for the EDI purist or an EDI tool vendor we are only talking about delimiters. Plain and simple. As an EDI purist your transactions have always (and as they should) been driven by the application's requirements. Well now, the application is simply asking, not for data requirements, but for delimiter requirements. One would argue, "but the transaction will grow in size." This is a valid argument if one is concentrating solely on the creation and transmission of transactions and not at the total business process. In this context, I urge you to review the article titled 'Introducing XML/EDI.... "the E-business framework"'. Hopefully you will sense the focus of the article is on application-to-application exchange and what XML/EDI brings for making better solutions. Your reaction to labeling the XML portion as an application-to-user tool is quite common, for this is the obvious use of the XML facilities. We are proposing using the rich document object model to house our information in ways which are impossible with the simple EDI tree. The article continues to discuss the attributes of XML/EDI which deal with business problems traditionally not in the realm of an EDI purist. Why does the article address these? XML/EDI documents are not bounded to the exchange between organizations, XML/EDI documents are intended to flow into an organization and be used by an organization's processes. For EDI to succeed in E-business systems, this is a must. No more can we box our world only to the transmission aspect of the process. The last portion of the article addresses interfacing with disparate systems. This is where we might loose your support - because the article not only describes the tools of the purist (template and rule based mapping) but discusses other tools which are afforded to us by XML/EDI if we choose to use them. These new methods and tools should be of interest you even if they don't fall within the purist toolbox - just as templating came to aid the EDI mapper in the past. One of our prime objectives is to include routing information into the XML/EDI document so we aren't tied only to the sender/receiver of the ISA. This might be of interest to you ;-) The bottom line: With millions of browsers installed across multiple platforms, each can potentially become a "trading partner" by building our EC components for batch and near real-time processing based on the Internet/browser infrastructure installed today. Thank you for your time, - The XML/EDI Group |