I have been watching for EDI-specific modules, and in general, tools like the module you mention are what we find. Tools that work on the segment level. The effort necessary to put together such things on the document level seems to be more than people are willing to do. Having done all that work, you might as well sell it as a translator or syntax-checking tool :). I would think a grammar approach might work, if you have file-based specifications to work from.

Are you wanting to check syntax of documents you're producing?

When you said "sell it", it excited the reptile part of my brain.

That said, I read Why is EDI still used, and how to deal with it? Yikes.

I looked at About Bots edi translator software. Quote: Programming language: Python.

Conceivably, one could use Inline::Python to interface Perl to the Bots open source edi translator.

(Fortunately, it seems that the authors of both pieces of software are active.)

GotToBTru, you mentioned a grammar approach. The Marpa::R2 folks are always looking for niches where Marpa can demonstrate its prowess.

EDI is one of the illustrations of the maxim "the nice thing about standards is there are so many to choose from." Well, almost. There are not that many to choose from. The most popular, ANSI X12 and EDIFACT, were developed by multi-industry committees and it shows it. The standards allow so many options that they might as well not be a standard. But it's kept food on my table since 1991.

Because very frequently trading partners supply each other with written specifications, I have often thought an automated method to read those files (maybe based on a grammar) would help with developing a practical system to validate a particular document for a particular trading partner, without having to put together the full standard for the hundred of document types, each composed of some subset of thousands of segment types, each of which is composed of a subset of thousands of element types. Because even if the standard says, for instance, a G62 segment is required in a 204 document, a particular trading partner can say it isn't required for them, and the same personalization can happen at the element level. Ranting aside, I should actually try this sometime. The potential time savings could be significant.

You want to hear something funny? Some people think XML would be preferable.

But God demonstrates His own love toward us, in that while we were yet sinners, Christ died for us. Romans 5:8 (NASB)

---

Thanks GotToBTru
yes, I'm looking at something where we can check edi syntax - e.g. MIN/MAX length, dependent/mandatory segments/qualifier and get specific error messages. There are online tools/editors available; but I wanted something to be automated.
Thanks for the tips - yeah I think a self dictionary should help as well.

In my limited EDI experience, much like with an XML schema -- I wouldn't trust anything you get to perfectly/fully comply. I like the approach of treating it like an unrestricted DOM and dealing with whatever comes down. People end up sticking weird things into the wrong fields anyway, and business rules will often further restrict things.

What's your use case?

Thanks Laurent R
I tried with some simple edi errors and opening/parsing a file - but it didn't throw any error. Also parse is not returning anything (I believe).

Not returning anything is a failure suggesting that the document is invalid. Unfortunately, it's not telling what or where the problem is.

Of course, as GotToBTru pointed out, between any 2 trading partners, what is and isn't valid might not match what is agreed upon with another trading partner. (And even when the right technical people are involved in the negotiations, the Golden Rule¹ applies.)

I'd start from known valid documents to verify the EDI parser you are trying to use can actually parse them correctly. If you can't find a parser that works for the documents you need it to process, you may have to write your own.

---

¹ "He who has the gold makes the rules."