If Microsoft wrote this, we would be up in arms: “people have been able to exchange spreadsheets using completely undocumented formats, such as Excel’s, for many years so this notion that documents “can’t be exchanged” until every jot and tiddle is written down is simply untrue.” What a snowjob! Actually, the quote comes from the ODF website.
But the thing that freaks me out more is the definition of an Open Standard given on that same page: on the one hand they say that implementations of Open Standards may be extended, or offered in subset form but on the other hand that you cannot have licensing requirements to inflict embrace-and-extend tactics. But it is the Hacker’s fallacy: embrace and extend is not obviated by open licensing, because most people do not have the technical capability to code up their own alternative to their platform or vendor’s immediate offering. We need non-fuzzy Open Standards because not everyone has the power or capability or deadlines to take advantage of Open Source or Open Licensing: standards should reduce the risk from the decision to outsource (i.e. purchase or download) systems and applications. In practise in Open Formula, they seem to be doing things the right way, and are having conformance levels: well-defined groupings of functionality in clear namespaces.
In David Wheeler’s discussion which the ODF site cites approvingly, Wheeler adopt’s Bruce Peren’s criteria but falsely, as far as I can see, ties Peren’s “Ability to create extension or subset” with Krechmer’s “Open Interface”.
The ability to create extensions or subsets willy nilly is the antithesis of a standard. It is the difference between “I bought product X because it says it supports standard Y but it often fails and I am pissed” and “I bought product X because it says it has partial support for standard Y and I accept it doesn’t work completely.”
Procurement, CIO and technical evaluators, when looking at adopting Open Standards, need to push against partial implementations. When a standards body feels their technology is big enough that there is the risk of partial implementations, then adopting conformance levels (especially where these conformance levels are tied in a simple way to namespaces) is a really reasonable and practical approach (no criticism of Open Formula in this regard!)
However, conformance levels undermine interoperability. Organizations interested in maximum interoperability must forgo the fullest-functionality conformance levels. (Third party products producing or consuming Microsoft’s formats will have exactly the same issue, by the way: this isn’t ODF-bashing but a continual problem with optional parts to standards.) In the long term, the market decides but in the short term we must trade-off interop and fidelity.