Microsoft Office is using an artificially complex XML schema as a lock-in tool

Respect to MS for keeping the lights on.

People need to understand that there is no MS format per se, but different standards from which you can choose. Years ago, when OpenDocument was fairly popular, MS was kind of hesitant to use an XML format. XML is a strict format, no matter the syntax.

And I bet that MS intended such a complicated format to prevent Open Source Projects from developing parsers and MS from losing market share this way. I bet there are considerations about such a strategy discussed at the time, buried in Archive.org.

On the other hand, MS didn't want nor see the XML chaos, which would follow later on. XML is a format, and all it demands is being formally correct. It is like Assembler, fixed instruction sets with lots of freedom, and only the computer needs to "understand" the code - if it runs, ship it.

ZEN of whatever cannot be enforced. JavaScript was once the Web's assembly language. Everything was possible, but you had to do the gruntwork and encapsulate every higher-level function in a module that consisted of hundreds of LoCs. Do in hundreds of LoCs, what a simple instruction in Python could achieve with one.

Babel came, TypeScript, and today I lost track of all the changes and features of the language and its dialects. The same goes for PHP, Java, C++, and even Python. So many features that were hyped, and you must learn this crap nevertheless, because it is valid code.

Humans cannot stand a steady state. The more you add to something, the more active and valuable it seems. I hate feature creep — kudos to all the compiler devs, who deserve credit for keeping the lights on.

Which they then carried over into OOXML.

Just to be clear, MS has back then and recently again repeatedly shown very clearly they the whole embrace extend extinguish thing is the core of their action for most things open or standardized(1). And what is a better way to "extinguish" open text standards by making one themself which is build in a way guaranteed to not work well, i.e. fail, for anyone(/most) but first party MS products and then use that to push the propaganda fud that open text standards just can't be good.

So I'm very sure them having an obscure, hyper complex, OOXML "open standard" format where actually implementing it standard compliant is far from sufficient for correct displayed/interpreted documents is a very intentional thing.

But if you already have a mess internally it is a very good move to just use/expand on that, because it does give you a excuse why things ended up how they are and save implementation time.

----

(1): disclaimer: In between there where a view years where they acted quite friendly; Specific dev of MS still love Open Source in a honest way; in some areas open source also has won; and in some places it's just a very bad time vor "extend and extinguish" so it's not (yet) done; And sometimes it's done very slowly and creepingly; So yes you will find good MS open source project and contributions. But its still pretty much everywhere no matter in which direction you look as long as you look close enough.

like XML is a mark up language so it _should_ interleave quite "naturally" and well for text formatting tasks (i.e. see OpenDocument example or supper simple "ancient style" HTML)

but OOXML looks more like someone force serialized some live OOP object hierarchy with (potential cyclic) references and tone of subclasses etc.

tl;dr: i.e. it looks a loot similar to a simplified form of how text editors internal represent formatted test

like w:r looks like a text section, you could say a r_ow of wide characters or words, w:p looks like a subclass of a implicit type which is basically a `Vec<w:r>`, w:pPr looks like ".presentation" property of w:p, same for w:rPr, probably both being subtypes of some generic Presentation base class. w:t looks like a generic `.text: String` property. w:pStyle looks like a property of Presentation or it's ParagraphPresentation sub-class, it's `w:val` property makes it look like it's a shared reference which can be looked up by the key `"Para"`. w:b is just another subclass of Presentation you can use in any context etc.

which opens the question

"do they mostly just dump their internal app state"?

and did they make their format that over-complicated and "over" flexible so that they can just change their internal structure and still dump it?

which would also explain how they might have ended up with "accidentally" incorrectly implementing their own standard around 10 years ago during early OOXML times

and if so isn't that basically "proof" that OOXML isn't really an open format but just a "make pretend" of one?

Considering how little most free software makes they can't afford to do a lot of things. It's not a hard bar to hit.

What surprises me is how well LibreOffice handles various file formats, not just OOXML. In some cases LibreOffice has the absolute best support for abandoned file formats. I'm not the one maintaining them, so it's easy enough for me to say "See, you managed just fine". It much be especially frustrating when you have the OpenDocument format, which does effectively the same thing, only simpler.

Death to user friendlyness! Advanced users only! /s

For most documents nowadays it makes no sense to see them as a representation of physical paper. And the word paradigm of representing a document as a if it were a piece of paper is obsolete in many areas where it is still being used.

Ironically Atlassian, with confluence, is a large force pushing companies away from documents as a representation of paper.

Ofc, if we stop really caring what things look like we could save lot of energy and time. Just go back to pure HTML without any JavaScript or CSS...

You want to be able to do everything just right for the looks. Because there always will be someone negotiating down because your PDF report does not look right and they know a competitor who „does this heading exactly right”.

In theory if you have garbled content that is not acceptable of course, but small deviations should be tolerated.

Unfortunately we have all kinds of power games where you want exact looks. You don’t always have option to walk away from asshole customers nitpicking on BS issues.

None of the two conditions are reality, of course.

So yeah, that’s not happening.

similar if someone random non technical person just needs to write idk. 5 paragraphs of text with a head line, no high requirements for formatting, no kind of templates, no anything fancy why would you force them to not have WYSIWYG if that is the perfekt fit for their use case in every single aspect?

Similar markdown doesn't scale to a lot of writing requirements, like _AT ALL_. I know because I have written pretty much any thesis or larger reports etc. during my studies in markdown. And I had to step out of markdown all the time. Weather that is by using inline latex, or by tweaking markdown to PDF conversion templates (by interleaving non mark down sources with markdown by splitting the markdown into many different files and folders which each could be markdown or anything else, and/or inline latex to include non markdown sources imported into latex) etc. It was a nice pipeline, but it also wasn't really markdown anymore, but instead some amalgamation of markdown LaTex and other things. As a programmer that was fine, but that doesn't scale at all to the "standard" user of office applications.

Many documents are created for looks rather than content.

OOXML was, if anything, an attempt to get ahead of requirements to have a documented interoperable format. I believe it was a consequence of legal settlements with the US or EU but am too tired at the moment to look up sources proving that.

Being able to layer markup with text before, inside elements, and after is especially important --- as anyone with HTML knowledge should know. Being able to namespace things so, you know, that OLE widget you pulled into your documents continue to work? Even more important. And that third-party compiled plugin your company uses for some obscure thing? Guess what. Its metadata gets correctly embedded and saved also, and in a way that is forward and backwards compatible with tooling that does not have said plugin installed.

So no, it wasn't 'hype'.

The OOXML format is likely a not very deeply thought out XML serialization of the in memory structure or of the old binary format, done under time pressure (there was legal pressure on Microsoft at the time).

This is just not right.

They where not required (AFIK) and in some edge cases also didn't provide a perfect conversion of all old documents to the open format. Actually even just converting between different versions of their proprietary formats had a tendency to break things sometimes! (back then)

> unbelievable XML hype that existed for a short time in the late 1990s and early 2000s.

(EDIT: actually 2006, so uh, maybe XML hype) we speak about ~2010, the hype was pretty dead again at that time, and the main reason they choose it is to position it as "completion" to emerging standardized open office document formats which all used XML as markup language (except they don't really use XML as mark down language but more like serialization to JSON but way more complex, but that doesn't matter they mostly need to convince not supper tech affine people about them "no longer trying to hamper competition" to preclude legislative action and governments from switching to other office suites due to the closed format making them worry).

so they where more then able to

- do a clean design, if anyway a lot of old "proprietary" documents break subtly when converting it doesn't matter (and they did break)

- just adopt OpenDocument format

It is complex but not complicated. You can start with just a few small parts and get to a usable and clean document within hours from the first contact with the languages. The tags and rules are usually quite self-describing while consice and there are tons and tons of good docs and tools. The development of the standards is also open and you can peek there if you want to understand decisions and rationals.

big reason for that is that they where not designed for modern requirements like being used as a general purpose application UI toolkit

especially CSS was designed printable documents, not modern websites

and HTML was designed to represent the core semantic structure of a "classical" document (and not a too fancy one either), with minimal formatting (e.g. bold, italic, underline) but even on old websites it was very common to not be used like that at all (e.g. think old table for the whole site to create header and side bar tricks, now doable nicer with HTML5/modern CSS)

so its kinda a markup and style language chosen in the very early internet days only to realize shortly later that websites develop in a direction very mismatched to the designs of both languages (but both happen to be squeezable into their new roles, barely).

Kinda funny. But not really the situation behind OOXML.

One example I work with sometimes is almost 1MB of xsds and thats a rather small internal data tool. They even have restful json variant but its not that used, and complexity is roughly the same (you escape namescape hell, escaping xml chars etc but then tooling around json is a bit less evolved). Xml to object mapping tool is a must.

and most of the time they do not use their open standard, but the other document type.

The artificial vendor lockin is real.

You might not add features, but well that is most likely losing proposition against those competitors that have features. As generally normal users want some tiny subset of features. Be it images, tables, internal links, comments, versions.

What do they expect people to do, remove features in order to support other formats? Users won't like that.

What is it about serializing XML that would optimize the expression of a data model?

Obviously parsing the XML is trivial. What is not trivial is what you do with parsed XML and what the parsed structure represents.

everything on top of the XML AST is the issue

As for complexity, an illustration-- while using M365 I recently was confounded by a stretch of text that had background highlighting that was neither highlight markup, not paragraph or style formatting. An AI turned me onto an obscure dialog for background shading at a text level which explained the mystery. I've been a sophisticated user of M365 for decades and never encountered such a thing, nor have a clear idea of why anyone would use text-level background formatting in preference of the more obvious choices. Yet, there it is. With that kind of complexity and obscurity in the actual product, it's inevitable the file format would be convoluted and complex.

or MS might find itself accidentally toasting themself

a lot of places (including very important MS Office customers) insist in a open document format for various reasons

if MS convinces people that LibreOffice and similar is toast because they can't afford keeping steep with the format in question because it's too expensive they also might end up convincing this customers that it's also too expensive to _them_, and try to find way to switch away from MS Office

A lot of people are locked in because those import/export features are typically imperfect (or perhaps the documents themselves are) and will badly and often "invisibly" (to the non-Office user) break something.

Its called antitrust.

What you want is a compiler (e.g., into a different document format) or an interpreter (e.g., for running a search or a spell checker).

That's a task that's massively complicated because you cannot give an LLM the semantic definition of the XML and your target (both typically are under documented and under specified). Without that information, the LLM would almost certainly generate an incomplete or broken implementation.