But really, I would look at the XML file itself and see if there was a problem with it- if it fit the standards documented on this site. If it didn't, then I'd blame Jeff/promash. If it did, then I'd fix my code.
But what if ProMash did fit the spec and so did your program? I believe the point here is that two people can implement the 1.0 spec "correctly" and still end up generating recipe files that aren't compatible with each other. This goes against the whole premise of BeerXML and must be fixed.
It's really not that uncommon for the second generation of anything to be extensively different from the first version. I think the first version is usually just a best-effort realization of the ideas floating about and serves to test the real-world usefulness of it and interest in it. Version two is about addressing the myriad issues which have arisen (many unforseeable) and redesigning it in a smarter way now that everyone's conviced it truly is a worthy, useful endevor. I think it's also not uncommon for software to break compatiblility with the initial version when this happens. Look at GNOME (the Linux desktop environment), for example. Version 1.0 to 2.0 was a heck of a change and flat out broke most software built for 1.0. I can still hear the reverberations of the people screaming bloody murder from when this happened. It's now quite a few years later and while some software was never ported to the new version and, thus, disappeared completely, the community as a whole has benefited greatly from the change by having a much better system IN THE LONG RUN.
I also agree that the current spec requires too many elements for the basic exchange of a recipe. I think there's a fine line between recipe formulation systems and recipe database systems but the line should exist. I'm the webmaster for a medium sized homebrew club and I would like our users to be able to enter and exchange recipes on our website without worrying about actually "formulating" a recipe. Through a series of pulldowns and entry boxes, I'd like a user to be able to enter basic information about the ingredients of the recipe and minimal steps involved for mashing and fermenting and nothing more if they don't want to. The ingredients and steps could then be saved to a BeerXML file, someone else would download that file, import it into their formulation software and come up with projected results for IBUs, SRM, OG, etc. The 1.0 spec seems to favor recipe formulation and evaluation in some spots rather than simple recipe creation and exchange. I also do some PalmOS development and would like to create the same type of minimalist recipe exchange system there. Certainly, I don't want to have to get into formulation details on an embedded platform like that.
3. Get rid of the caps
Oh please, please, please....camelCase/studlyCaps/all_lower/whatever - anything but ALL CAPS. The caps make my eyes bleed everytime I have to look at a BeerXML file
Well, first I'd call hell to see if it was snowing, because the day Promash supports beerxml...
LOL...I with ya on that one. I've actually heard a rumor that he's considering adding support whenever/if ever he updates ProMash to bring it into the current century. Personally, I don't use it since it doesn't run on Mac OSX or Linux but it would be nice if the many people who do use it could exchange their recipes with the rest of us striving for a common format.