Is OOXML Artifically Complex?

Origins and Design of OOXML

• Several commenters argue OOXML is essentially a direct XML serialization of Office’s legacy binary formats, carrying decades of cruft tied to in‑memory data structures and performance constraints of the 80s/90s.
• Backward compatibility for “hundreds of millions” of users and regulatory pressure (especially in Europe) are seen as key drivers; designing a clean new format or fully adopting ODF was viewed as too slow and risky internally.

Complexity: Necessary, Accidental, or Malicious?

• One camp: complexity is “inevitable” given Office’s enormous feature set and commitment to lossless round‑tripping of old documents. Cutting features to simplify the spec would have broken real users.
• Another camp: much of the complexity is unnecessary for an interoperable standard and exists because Microsoft just dumped internal representation into XML. That’s framed as technical debt and “self‑interested negligence,” not careful design.
• A more critical camp: the format and spec are intentionally hostile—full of “works like Word95/97” behavior tied to undocumented software, making faithful third‑party implementation effectively impossible.

Interoperability and Standards Politics

• Strong accusations that Microsoft “bought” or stacked national standards bodies to push OOXML through fast‑track ISO approval, over technical objections and despite overlapping with existing ODF.
• Some see this as classic embrace‑extend‑extinguish: creating a nominally open but practically proprietary standard to block ODF adoption in government procurement.
• Others argue both motives can coexist: backward compatibility and strategic obstruction.

Comparison with ODF and Other Formats

• ODF is praised for clearer, more “markup‑like” structure in simple cases, but also criticized as ambiguous, underspecified, and itself complex once all referenced specs are counted.
• Debate over which is more “open in practice”: OOXML’s detailed but messy serialization vs. ODF’s cleaner model but reliance on de facto behavior of LibreOffice.

Developer and User Experience

• Implementers report OOXML as painful: gigantic specs, odd date handling, namespace verbosity, implicit caches, and hidden coupling to Office behavior.
• Nonetheless, for many tasks (scripts that read/write documents, extract images, simple spreadsheets) OOXML’s zipped‑XML container is seen as a big improvement over old binary formats.
• Users largely prioritize fidelity over openness; this is cited as why Office remains dominant despite OOXML’s flaws and LibreOffice/Google Docs’ existence.