For the last several months Microsoft has been pushing for their Office Open XML (OOXML) office suite file specification to be accepted as an international standard by ISO, presumably to help them gain traction for future government contracts (look, this file specification is an ISO standard, it must be good).
As far as ISO/IEC DIS 29500 is concerned, it continues its steady progress towards standardship, however it seems that Microsoft's push towards this goal hasn't been without its bodycount. While the ISO site lists 29500 as a deleted standard, complementary reporting shows the process is still ongoing and OOXML will soon become ISO/IEC IS 29500.
In an ideal world, standards bodies would be incorruptible and lead to the publication and adoption of consistent standards across the user communities. Anyone who has followed the OOXML progress through ISO would think otherwise. The ongoing stoush regarding Microsoft's effort to get the ODF-killer that has yet to be properly implemented through the standards body has claimed some high profile casualties, with the national Standards body of Norway effectively self-destructing after 13 of 23 members of the technical committee resigned in disgust.
ODF itself may be on shaky legs, with reports that the ISO/IEC committee responsible for overseeing OOXML (SC 34) is pushing to have control over ODF (ISO/IEC 26300), as well. With Microsoft controlling a large percentage of SC 34, many of the same people who objected to OOXML's move towards a standard have begun to sit up and take notice of this latest move.
The big fear amongst these people is that if SC 34 is able to take control over ODF from OASIS (the body currently responsible for ODF), then Microsoft might try to leverage its voting bloc on SC 34 to neuter the competing specification.
Even if both formats are accepted as standards, there will be plenty of material available for security researchers to dig through. Reading through ISO/ECMA standards, or even RFCs, might not be fun for everyone, but there is an important security aspect to having well documented standards.
In the first case, documented standards will highlight design flaws. It could take years for design flaws to make themselves apparent , or at least widely publicised.
In the second case, documentation serves as a reference point that can be used to find weaknesses or deviation in individual implementations. Once the major design flaws have been rectified, this is the aspect that will provide the greatest number of opportunities to uncover security weaknesses or other shortcomings.
So, even if international standards bodies have been shown to be vulnerable to external pressure and can be gamed much like any other corporate body can, the products that they produce will still have relevance to developers, end users, and security researchers alike.