After reading this, I really hope you're lying about being on a standards committee. Unfortunately, I am equally convinced that you are in earnest. The problem is not Microsoft "opening up their own work", it is the fact that they say they are, but they really aren't.
The whole idea of a standard is that I could take a copy of it, sit down at my computer and implement it (whether that means implementing a client/server, or the parser for a file format). With Microsoft's OOXML, that has not been the case so far. The standard has been sprinkled with little nuggets that are closed, that Microsoft alone can implement. References to proprietary work that do not open up that self same work. Moreover, there are other sections that act as little more than XML wrappers around Microsoft's proprietary formats. In other words, I still couldn't parse out a full OOXML document without also reverse engineering a proprietary format. I want you to think for a moment and list any other standardized file formats that allow this kind of nonsense. If Microsoft wants to keep their formats proprietary, that is their own business, but a proprietary format flies in the face of the very idea of a standard (which is interchange; if interchange were unnecessary, standards would be as well) and should not be allowed to become one.
If Microsoft had introduced a truly open standard to the ISO and ECMA, the reaction would have been quite different. There would have been a lot of people who would have been wary of using it due to Microsoft's long standing policy of Embrace, Extend and Extinguish. Others would have considered it superfluous after ODF had already passed. But you would not have seen the outrage against this mock standard.
Yes. However, most large standards do also have some things that are not essential to the implementation of the standard that are in a vendor defined format. For example, the vendor specific sense data in the SCSI Primary Commands standard.
Actually just do a search in any of the SCSI or Fibre Channel standards docs for the term "vendor specific". You'll find a number of things that are not generally critical to implementing the standard that are done in a vendor specific way. They aren't critical, but leaving placeholders for them in the standard allows vendors to implement things that can add value for their customers, that other vendors might not care to implement, without breaking compatibility with the standard.
So there Sense Data types 0x80 to 0xFF are reserved for vendor specific implementations so that vendors can pass additional information about their SCSI target device back to a SCSI initiator without breaking with the standard.
Sometimes vendor specific represents things that different companies have implemented in different manners, and they don't see the need to standardize, and sometimes it represents company's proprietary implementation of features that they use to differentiate themselves in the market.
So what are the things that other companies are complaining about in the standard? Are they really critical parts of the standard, or are they minor things?
Every company has some things they don't open up in the standards process, they just can't be things that prevent the implementation of a compatible implementation within the bounds of what is common, and not listed as vendor specific.
Obviously different companies and organizations are going to disagree on what might be allowed to remain vendor specific, especially when you are dealing with some of the open software groups that basically oppose private ownership of intellectual property.
In reality, few companies want to just give away all the details of software they spent millions if not billions of dollars developing.
For OOXML to be a reasonable standard most companies should be able to save their documents in the format without using any vendor specific parts of the format, or the data in the vendor specific portions should not be critical to reconstructing the data.
I heard some rumors that some of the issues involved compatibility with previous versions of Office. Since this is a file format, I suspect that they are talking about including data or objects created in a previous version of office in a new file.
That's a difficult subject to address. Microsoft probably doesn't want to open up all their previous file formats as well as OOXML, but they do need to maintain backwards compatibility, and backwards compatibility is in customer's best interest.
However, allowing objects from a non-standard format to be included in the standard format, is something that open source people aren't going to like very much. It goes in opposition to the viral approach they use with GPL to try and open up all software.
However, it's not something that hasn't been done in many standards in the past, and it's also not something that consumers can't avoid if they wish to make their documents compatible with other company's office software.
To remain compatible, consumers would have to redo their old documents. By banning the use of objects from old formats, other companies are trying to force consumers to redo old documents.
That's not in the best interest of consumers, but it is in the best interest of companies that are producing competing products.
Not surprisingly, the companies that supported ODF opposed approving OOXML, while the newer members overwhelmingly voted to approve it. OOXML got majority support easily, they just had trouble getting a 2/3 super-majority.
Moreover, there are other sections that act as little more than XML wrappers around Microsoft's proprietary formats. In other words, I still couldn't parse out a full OOXML document without also reverse engineering a proprietary format.
Despite your naive to the contrary, the existence of such is not unusual in itself.
The question is what proprietary formats are they referencing. Is it for backwards compatibility, or are they features used in the current versions of Office as well? Are they crucial to the implementation, or can you ignore that data without losing significant features?
If Microsoft had introduced a truly open standard to the ISO and ECMA, the reaction would have been quite different.
Many of those opposing this would not be happy unless Microsoft released every bit of proprietary information related to every version of Office Microsoft ever developed. However, since some features of Office have been tightly integrated with Windows at least in some versions, they probably wouldn't be happy unless Microsoft completely released all information that has been proprietary in Windows as well.
Standards, only standardize the portions they say they standardize. They only open the formerly proprietary data that they document, which is almost always less than many in the "free software" crowd would like. They are going to be "outraged" about anything short of the end of intellectual property.