You're probably right about the majority of people's everyday grammars. But I'll bet dollars to donuts there are at least a dozen standards out there that could apply. Medical records? Air-traffic data? Building specifications? If there are a dozen, mightn't that warrant some sort of more general wrapper? This would be in cases where the software people already use is a black-box, and they can't do anything with the data basides what is shoved into a database w/ a limited interface. That's exactly the situation the company was in, so they asked me for help.

Of course, the maintenance of those standards is an issue. If I didn't know that this standard was fairly well accepted and rarely changed I wouldn't propose it as one of them. Clearly there won't be too many that apply. The idea would be to have grammars for the ones that apply, and to make them flexible.

Sure, I could create BAI::Format, in fact I already have (though a different name, still need to work on what its CPAN name would be). The problem is that it presumes to know what format you want your data returned in. It doesn't want to know the names of the bank account owners, it wants to know dates and amounts. I'll bet I'll never need the data structures again when I re-use this parser for another project, but I'll still need the parser. If I change it so that all the data is extrapolated into a large hash of hashes, I'll have a huge data structure, only about 15% of which I'll actually need.

The idea is that I supply the rules for how the file should look, and everyone who downloads the parser will only have to do the easy part, i.e. figuring out what to do with the data. Sure, it'll take some work on their part, but I'll just about guarantee that my solution wouldn't work for them. If someone had done this for my project, leaving all the references to $item[x] out of it, it probably would have taken about 3 hours (less|fewer).

This still may be a bad idea, especially with the good points you bring up. I guess the real answer will rest on whether or not there are enough of these file formats (that aren't proprietary) to justify it.

Good comments, thanks.

MM