The "rub" with EDI is not the technology, but the particular business. I've worked on a couple different EDI projects in the utilities industry. Despite the "standards" for various forms, each company still has its own version of each form, or its own opinion of the way things should work. EDI Analysts need to know the business, the EDI standard, and the way EACH of their business partners interprets the "standards". And XML is no better (yet, as a replacement for EDI). At least it includes metadata which should help (eventually?). But the technology of EDI is just as simple as, if not simpler than, XML. So writing an EDI Translator in theory is a simple task. But whizzing contests between various vendors makes EDI a nighmare. Maybe it's different in industries where both vendors benefit from the exchange of information. But in the utilities industry, the only benefit of giving another company your data is that it satisfies government regulations. Good luck on your quest! But I leave EDI off my resume;)
The "rub" with EDI is not the technology, but the particular business. I've worked on a couple different EDI projects in the utilities industry. Despite the "standards" for various forms, each company still has its own version of each form, or its own opinion of the way things should work. EDI Analysts need to know the business, the EDI standard, and the way EACH of their business partners interprets the "standards". And XML is no better (yet, as a replacement for EDI). At least it includes metadata which should help (eventually?). But the technology of EDI is just as simple as, if not simpler than, XML. So writing an EDI Translator in theory is a simple task. But whizzing contests between various vendors makes EDI a nighmare. Maybe it's different in industries where both vendors benefit from the exchange of information. But in the utilities industry, the only benefit of giving another company your data is that it satisfies government regulations. Good luck on your quest! But I leave EDI off my resume ;)