UK XML expert and key player in the SC34 standards committee at ISO, Dr Alex Brown, has written (the day before April Fool's Day) a strongly worded blog Microsoft fails the Standards Test.
If his concerns that the new version of Office will not support OOXML Strict turn out to be well-founded, then I think he is right.
(I note that MS' recent API for transformations included some mention of Strict, so I probably have more hope than Alex: I have always called for more government, procurement and competition authority pressure on vendors to support and track standards.)
The corporations all come (to standards); they all go; it is a cycle and the game is to get mutually-satisfactory improvements out of them while they are at the table. If they don't implement a standard, it must be because they decided to, not because they were denied any opportunity.
And certainly I think that OOXML Transitional (Part 4) should be de-standardized as soon as possible, regardless of Office's use of it. It has served its purpose and is now more than just a distraction, it is a threat to the standard that was actually accepted (i.e. to Strict). The initial version of the ISO Standard left out a key sentence that the BRM had required about Transitional, which has been restored now: The intent of this Part is to enable a transitional period during which existing binary documents being migrated to ISO/IEC 29500 can make use of legacy features to preserve their fidelity, while noting that new documents should not use them. (The emphasis is mine.)
I think Microsoft has shown itself to be very ready to provide the documentation, to send good people to meetings, to put in editing resources, to put in changes that reflect reality better, and even to make whatever XML syntactic adjustments are necessary. However, I have not seen any corresponding willingness to alter anything that is out of the control of the serialization/deserialization routines: anything to do with OOXML features or behaviour.
Lets take a specific example. At the BRM (the Ballot Resolution Meeting which negotiated various changes to the rejected text of the standard which made it ultimately acceptable for national vote), one of the key Australian positions was that the spreadsheet function CEILING() should work mathematically correctly. Excel is used in schools and many mission-critical situation.
In discussing this with the ECMA people, we came to a compromise that a new function ISO.CEILING() should be made: no old spreadsheets would alter functionality (they could have been written with workarounds, after all) and people could use the new, correct function. People may not realize it, but actually the formula you see associated with a spreadsheet name may not be the formula stored by the spreadsheet: in particular, some function names may be localized into different languages. So there is scope for a setting that says "Use ISO.CEILING() in the serialization file but just display the simpler CEILING name on screen."
Another advantage of this would be that it would lead to a module system, such as Open Formula has, more readily than, say "CEILING.ISO()" would (that was another suggestion.)
But when I looked recently at the function language for Excel in the new draft, I did not see ISO.CEILING() at all. There was, IIRC, a fixed function with a different name. Now I want to stress that I don't think it is worth getting too upset based on features that make it into this beta version of software or that pre-release version. However, it certainly is the time to point out what the requirements of the standard are: better now than in some service pack.
So while it is great if Excel gets a non-broken CEILING() function, what's the story with deliberately using a non-conforming name? Are the fiefdoms so strong in the Office team that no external input or constraints can possibly be tolerated? Microsoft has such an investment, it will be interesting to see if they throw it away because of sabotage by internal personalities who may see the standards requirements as challenges to their power rather than an opportunity to break up old logjams.