There is more OOXML controversy in the news, this time in Denmark. I don’t claim to understand all the nuances of the accusations, since I don’t read Danish, and Google Translates makes it sound at times like a discussion about loaves of rye bread or something, but the gist of it, as I can surmise from this account, is whether Office 2010 will “support the complete ISO-approved version of OOXML”. Microsoft’s spokesperson says it will. Mogens Kühn Pedersen, chair of the Danish Standards Committee, says it will not.
This is the kind of dispute where you can go around in circles with for days and not reach agreement. The problem is they are arguing over words, not facts, and they do not agree perfectly on the meaning of the words. Words like “support” and “complete” and “conform” are used in different ways, with different meanings and intents.
Let’s try to escape the equivocation and instead try to establish the underling facts. I can’t promise that this will clarify the situation any. In fact I suspect we’ll end up even more confused about what exactly Office 2010 actually supports. But replacing a false certainty with an honest uncertainty is progress of a kind. It gives us something we can build on.
First, we need to acknowledge that OOXML entered ISO as one standard, and was transformed, via the BRM and ISO ballot, formally into 4 standards, ISO/IEC 29500 Parts 1, 2, 3 and 4. Within these parts are are several different conformance targets and conformance classes. In particular, these 4 standards encompass two different and incompatible schemas for many of its features: “Strict” and “Transitional”. What Microsoft submitted in the Fast Track is essentially the “Transitional” schema. What was created by the BRM was the “Strict” schema. This is where Microsoft made most of its “concessions” in order to turn “No” votes into “Yes” votes. So things like support for spreadsheet dates before the year 1900, the elimination of VML graphics, etc., these are all in the “Strict” schema. All the legacy “DoItLikeWord95” garbage was in “Transitional” only. Several NBs voted to approve OOXML because the assertion that “Transitional” would not be written in documents produced by future versions of MS Office. The promise was that it was…well…transitional, for moving legacy binary documents into XML. Few people want to support two different document standards (both ODF and OOXML) in the first place. But to require support for two different and incompatible versions of OOXML — that is simply intolerable.
In any case, because of these two conformance classes, anyone who claims that their product supports “OOXML” in an unqualified sense, without stating which conformance target or conformance classes they are supporting, is not stating anything of substance. It is like trying to buy an electrical plug adapter by just saying “I need electricity”. Merely saying “conformance to OOXML” means nothing. You need to state the conformance targets and classes that you support. Remember, the conformance language of OOXML is so loose that even a shell statement of “cat foo.docx > /dev/null” would qualify as a conformant application. I assume that Office 2010 supports at least that.
Of course, the alleged assertion that Office 2010 supports OOXML “completely” is a bit more problematic. What exactly does this mean? Does this mean that Office 2010 supports all conformance classes and targets of all four parts of OOXML? Including being a Strict consumer? A Strict producer? That would be a good thing, IMHO, if it were true. But that is not what ISO/IEC JTC1 SC34/WG4 was recently told in Seattle, where they were told that Office would not write out Strict documents until Office 16. That would put it out to the middle of the next decade, assuming the typical 3-year Office release schedule.
So I’ll lay out my assertions (with the caveat that Office 2010 is not complete and shipped yet) as:
- Office 2010 will conform to the Transitional consumer and producer classes defined in the OOXML standards. Any bugs that are found in the shipped version of Office 2010 will be “fixed” by retroactively changing the standards to match what Office actually does, as is currently being done by Microsoft-packed SC34/WG4 committee with similar bugs found in Office 2007’s OOXML support.
- Office 2010 will not have conforming support for OOXML Strict producer or consumer classes.
- Office 2010 will write dozens of non-interoperable, proprietary extensions into their OOXML documents, extensions which are not defined by the OOXML standards and which have not been reviewed or standardized by any standards committee and which will not be fully interoperable with other OOXML editors, or even with previous versions of MS Office.
So instead of arguing over the meaning of “support” and “complete” I suggest some alternate questions for Microsoft, to give them the opportunity to clarify exactly what kind of support for OOXML will be coming in Office 2010:
- Exactly what ISO/IEC 29500:2008 conformance classes and targets will Office 2010 conform to?
- Is this contingent on first changing the conformance requirements of the published ISO/IEC 29500:2008 standards to match what Office 2010 actually supports? Or is there a commitment to support the published standards as they was approved by JTC1 national bodies? In other words, is Microsoft committed to conform to the standards, or are we back to changing the standards to “conform” to Microsoft?
- Will Microsoft Office 2010 write out only markup that is fully described in the OOXML standards? Or will it write out proprietary markup extensions that are not fully defined in the standards? In other words, will Office 2010 be “strictly conformant” with the ISO/IEC 29500:2008 standards?
The problem you run into here is that there are really two different OOXML standards: the new and improved OOXML Strict conformance class, the one that was “sold” to ISO NBs, the one that garnered the approval votes, and then the old ugly one, the “haunted” specification, the Transitional conformance class, supported only by Microsoft Office. Anyone considering adopting OOXML should have perfect clarity as to which one they are adopting, especially since these are two very different standards, both formally and logically. Just as it is problematic to speak about OOXML support in a product without stating which conformance classes and targets are supported, it is equally a defect of any adoption policy to be loose in what version of OOXML is being proposed for adoption.
IMHO, if you must state a requirement for OOXML (along with ODF), at least specify it clearly, and state a requirement for “strict conformance” (meaning no extensions) of the Strict conformance classes of ISO/IEC 29500:2008. To do otherwise is to essentially specify a requirement for the use of Microsoft Office and Microsoft Office alone.