So the next question would be: Are there definitely certain things that are in the "native" file/app that you would like to see exported, but are never made available by any of the available export options?

If the answer to that is "yes", it might be worthwhile pointing this out to their customer support people -- maybe they know something you didn't find, or maybe they would consider adding it.

If you asked them for information about the "native" file format so you could parse it out for yourself with Perl, either they would provide that information, or else (more likely) they'd point to a clause in their EULA that specifically prohibits you from having that information or trying to figure it out on your own -- this tends to be the norm for commercially-developed software, and might have something to do with why no one has posted a CPAN module for this package yet.

So unless their customer support is really supportive, your only hope is that everything you need could be exported, even if it means creating two or more distinct export files (XML and "custom template flunky3" and ...), then using perl to integrate those. Yuck.

Thanks. You've pretty much summed it up. I don't really have the time to reverse engineer the EGP format from scratch (much as I'd like to). But I feel it would be a good investment in time to build on someone else's work.

It remains to be seen how much time will get sucked up explaining how to do the export dance to non-techi EGP users (they don't understand why they can't just import their .egp files into the application directly). In the end that could tip the balance.