OOXML = MS XML = Proprietary format
I hope that by now you already identified why the OpenXML or Office Open XML document format is by no means an open format for documents and so it must not be a standard.
First of all you need to understand and understand clearly that OOXML doesn’t stand for OpenOffice XML, obviously not, this was a Microsoft (M$) trick to make ignorant people think that that format is really open, when in fact it isn’t.
To avoid confusion you better say Microsoft XML format, or M$ XML, when talking about that format; as mentioned in some comments here.
So, why is it that it’s a proprietary format and doesn’t fit as a standard? Well, I really think you need to read about it first and don’t get hooked on Microsoft’s rhetoric, I’ll suggest some links at the end of this blog post that you should read, but for now here I’ll try to mention some concrete items on why the M$XML is a proprietary format and shouldn’t be even considered for standardization (all extracted from several sources):
- Record time to create and review 6,456 pages of a “standard” that is not defined at all and depends on a lot of propietary (and buggy) functionality from Microsoft, which by the way will never disclose. (And most likely will sue anyone trying to implement them, either reverse engineering or not.)
- It’ll take anyone, except Microsoft, a lot of time and resources to be able to implement a subset of that so called specification.
- This specification does not like real standards, instead of using MathML or SVG, Microsoft wants you to implement something unknown and buggy that’ll take you years to accomplish. For their sole advantage of course.
- It is not open. When you say “AddASpaceAsWord95Does, and by the way, I’m not going to tell you, figure it out yourself”, then I’m not seeing the openness in here. It’ll be different if it says something like “when reading a Word 95 document change all of the white spaces to be 1.1 of its normal width”. I wonder how much usefulness IPv4 or IPv6 would have had if the specification said: “The IPv4 Header format has the following fields: Version, IHL, Type of Service, Total Length, etc… [Guidance: To faithfully know the size of each field, applications must imitate the size used on M$ XYZ application, which involves many possible sizes and cannot be faithfully placed into narrative for this IPv4 Spec. end guidance]”, HA! Pretty funny.
- If Microsoft, having already the code, needs a lot of developers a year to create a file converter from scratch for Mac Word, how many developers and years any other company or open source group does need to implement less than a third of it when there’s no existing code available? (And existing code and/or standards available like SVG, MathML, etc., were knowingly excluded in favor of buggy proprietary functions.)
- As already mentioned in Groklaw, “[t]he easier a format is to learn, the easier it is to support. The programmers who create the tools you use will be able to create them more efficiently and reliably with the more understandable format.” In the end this means that you’ll have real choice (and competition, that is best for user’s pockets) if the format is clear, concise and easier. In addition, if it’s easier to support then you’ll hardly have problems with your document. If it’s more complex then it’s easier for it to get corrupted or that sometimes can’t be opened in a different version of the tool (M$ Office anyone?)
I think anyone (developer, software architect) can do a pretty easy exercise by thinking what kind of format they’ll define (specify) if they’re asked to create a standard that is to be implemented by any corporation and any open source community group in equal conditions to cover precisely the three business case (I think) points that are the goal of a standard format for office documents:
- A way to avoid vendor lock-in, giving the option to opt out from expensive and irrational licenses for a product, and have choice of applications that support the format
- Give companies, government, small and medium businesses, and individuals the chance to pick the application that best fits their needs, either with proprietary software (a fee involved) or open source, free, software.
- Retention and creation of documents, for whatever purposes, indefinitely. Without worrying if sometime in the future the provider of the application that we use disappears (bankruptcy or whatever), there should be at least 20 more options to pick from
If after doing that exercise someone comes up with a format like the M$ XML then I’ll really question if that person knows computer science, XML, technologies and even standards.
Here you have some links to additional useful information:
- Searching for Openness in Microsoft’s OOXML and Finding Contradictions (Groklaw)
- A notable achievement (An Antic Disposition)
- Self deprecating standards (Genii Weblog)
- How to hire Guillaume Portes (An Antic Disposition)
- Is Open XML a one way specification for most people? (Bob Sutor: Open Blog)
- Interoperability vs. intraoperability: your open choice (Bob Sutor: Open Blog)
- The Chernobyl Design Pattern (An Antic Disposition)
- Dark Corners of the OpenXML Standard (Slashdot)
- Is Office Open XML A One-Way Standard? Ask Microsoft (Shabanation)
- Format Comparison Between ODF and MS XML ~ by Carrera, D’Arcus, Eisenberg (Groklaw)
- EOOXML - What is a ‘contradiction’ at ISO and what are its procedures? - Updated (OpenDocument Fellowship)
- Deadline Looms to Express Concerns about ECMA 376 Office Open XML (Groklaw)
- Thought Experiments (ongoing)
- How Microsoft & Massachusetts played hardball over open standards (Computerworld)
- The Contradictory Nature of OOXML (Standards Blog)
