[troupo]

> OOXML is complex because it has to be.

What it didn't have to be is sections upon sections of "this behaviour is as seen in Word 95", "this behaviour is as seen in Word 97" without any further specification or context.

The main struggle for independent implementors was reverse engineering all the implicit and explicit assumptions and inner workings of MS Office software.

> But admitting that would have been hard. Easier to come up with conspiracy theories.

I actually read through a lot of that spec at the time. A lot of it was just lip service to open standards at a time when MS was under a lot of regulatory pressure.

[mmis1000]

> "this behaviour is as seen in Word 95", "this behaviour is as seen in Word 97"

The office relies on behaviour in windows itself "a lot". Even office mac or office web they made themselves isn't a 1:1 replica of the office on windows.

Let alone describe it as a standard.

"this behaviour is as seen in Word 95" sounds sloppy, but it is indeed the closest they can get.

Or what else can you do? You can't just also ship a installation media of word 95 and windows into the ISO standard, right?

[troupo]

> You can't just also ship a installation media of word 95 and windows into the ISO standard, right?

That's what they almost literally did. The spec is littered with "behavior of this program that has no specification and to see it you need to install it and run it"

And that's on top of re-inventing a bunch of specs in MS-only and MS-specific manner (like dates, for example)

[qcnguy]

That stuff happens because Microsoft don't know what the behavior is. It's just a bit which forks Word down some ancient code path that nobody understands and isn't properly documented. Given the huge effort that would have gone into producing this thousand plus page specification, is understandable why the spec writers would have given up at times.

I expect most people posting on Hacker News would not be able to write a satisfactory specification for their own software if they are working a large legacy code base.

[lozenge]

This is correct and there's no point fixing the bugs because it means the layout of the document will change.

[troupo]

> That stuff happens because Microsoft don't know what the behavior is.

They do. Or they did at the time. They literally had things like "save as Word 95" in their office suite.

> Given the huge effort that would have gone into producing this thousand plus page specification, is understandable why the spec writers would have given up at times.

Given the huge effort to produce it in unreasonable timeline they forced themselves into due to regulatory pressure, sure.

The whole OOXML came about only because some large governments said "well, we don't want to be beholden to black box document formats, and we might want a selection of vendors in the future, so ODF looks like a nice proposition compared to Word, actually".

So it was literally rushed through Ecma. MS submitted 2000 pages in December 2005, the spec grew to 6000 pages over the course of the yer, and got standardised in December 2006. So, only a year to significantly increase the spec and standardize it.

And then it was rushed through the ISO standards track which included things like "Swedish vote declared invalid, accusing MS of manipulating votes" https://www.linux-magazine.com/Online/News/Swedish-OpenXML-V... or "Netherlands automatically abstains from voting due to Microsoft" https://archive.ph/20120711220944/http://isoc.nl/michiel/nod... or "near unanimous 'No with comments' turned into 'Abstain' from Malaysia" https://web.archive.org/web/20090726171905/http://www.openma... or...

Google said it best: https://www.csun.edu/~hcmth008/odf/google_ooxml.pdf

--- start quote ---

In developing standards, as in other engineering processes, it is a bad idea to reinvent the wheel. The OOXML standard document is 6546 pages long. The ODF standard, which achieves the same goal, is only 867 pages. The reason for this is that ODF references other existing ISO standards for such things as date specifications, math formula markup and many other needs of an office document format standard. OOXML invents its own versions of these existing standards, which is unnecessary and complicates the final standard.

If ISO were to give OOXML with its 6546 pages the same level of review that other standards have seen, it would take 18 years (6576 days for 6546 pages) to achieve comparable levels of review to the existing ODF standard (871 days for 867 pages) which achieves the same purpose and is thus a good comparison.

Considering that OOXML has only received about 5.5% of the review that comparable standards have undergone, reports about inconsistencies, contradictions and missing information are hardly surprising.

--- end quote ---

Do not for a second assume that anything about OOXML was done in good faith. Well, apart from the thankless work that people assembling the standard did.

[qcnguy]

> They literally had things like "save as Word 95" in their office suite.

And what do you think that setting did? Forked execution down an alternative no longer maintained codepath instead of the rewritten version that wasn't quite compatible.

[happymellon]

Which shouldn't be in an open spec...

[troupo]

Ah yes. All the changes made to word just continued to work magically when "forked down an alternative codepath no one knew about".

And if that's the case, why was that specified in OOXML?

[mmis1000]

> save as Word 95

This is for format only and a lossy conversion.

Line break or whatever finer behaviour isn't preserved perfectly.

Or probably any conversion between different office version is a lossy conversion.

They (microsoft) truly don't know how their format behaves exactly at any time I believe.

Even office for mac or office for web behaves slightly different.

I don't believe they have a true spec (A pixel perfect one) about word document. Or they should use it on their office mac or office web first.