Our current approach sounds very similar to yours. You wouldn't know from the code that we are parsing EDI except for a method designed to handle the ISA segment. Everything else is table driven.

We haven't had to subclass our design for trading partners. We do have hooks that can call trading partner specific code Pre and Post file, and Pre and Post transaction.

>Currently, mine is hardcoded, on a per trading partner basis. There is a class definition that handles a specific transaction set (such as purchase order), then I subclass it specifically for a trading partner. The subclass implementation only has hooks for the mapping itself, and knows as little as possible about EDI or the business process itself. There is a master process that examines the file, and knows what kind of object (that part is table driven) to create to do the mapping.
>
>It is a work in process, and certainly is not as mature and bulletproof as what you have. It is for in-house use, so I can tweak and improve it as we go. Someday it will be complete. :)
>
>>
>>Our translators are table based, but in hind-sight, if I was starting from scratch, I think I would hard code the solution for performance reasons. Table based solutions can provide flexibility, but they are harder to debug.
>>