Live data from Hacker News

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

blog.documentfoundation.org

21–30 of 131 posts

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

#21
post #6

Earlier quoted context omitted.

You're not wrong, but it's funny that this same topic was posted just earlier today with a very different sentiment in the comments. https://news.ycombinator.com/item?id=44606646 But if you dig hard enough, there's actually links to more evidence of why it is that complicated... so I don't think it was necessarily intentionally done as a method of lock-in, but where's the outrage in that? /s "Complicated file format…

Weren't those reasons effectively...? 'special case everything we ever used to do in office so everything renders exactly the same' Instead of offering some suitable placebo for properly rendering into a new format ONCE with those specific quirks fixed in place?

What would that look like?

"You have opened your Word 97 document in Office 2003. The quirks have been removed, so it might look different now. Check every page before saving as docx."

"You have pasted from a Word 97 document into an Office 2003 OOXML document. Some things will not work."

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

#22
post #5

> Unfortunately, while an XML schema can be simple, it can also be unnecessarily complex, bloated, convoluted and difficult to implement without specific knowledge of its features. One could now use that exact sentence to describe the most popular open document format of all: HTML and CSS.

This is similar in zero ways.

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

#23
post #11
post #5

> Unfortunately, while an XML schema can be simple, it can also be unnecessarily complex, bloated, convoluted and difficult to implement without specific knowledge of its features. One could now use that exact sentence to describe the most popular open document format of all: HTML and CSS.

Can you be more specific here? HTML and CSS can't be described like that in my opinion. 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…

It's not about making a document.

It's about making software that would display a document in that format correctly.

I.e., a browser.

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

#24
What we should really do is abandon the WYSIWYG approach to document editing. This inevitably leads into vendor lock in.

Instead of perfect looks, we should focus on the content. Formats like markdown are nice, because they force you to do this. The old way made sense 30 yers ago when information was consumed on paper.

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

#25
post #11
post #5

> Unfortunately, while an XML schema can be simple, it can also be unnecessarily complex, bloated, convoluted and difficult to implement without specific knowledge of its features. One could now use that exact sentence to describe the most popular open document format of all: HTML and CSS.

Can you be more specific here? HTML and CSS can't be described like that in my opinion. 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…

The current HTML spec alone is a 1000+ page PDF, and I can't imagine the CSS spec being much shorter.

Wordsmithing your way around this doesn't make them any easier.

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

#26
post #12

This is a comical perspective to me. I've been ass-deep in core banking APIs where we generate service references from WSDL/XSDs. Some of the resulting codegen measures in the tens of megabytes for some files. I wouldn't even attempt to quantify the number of pages of documentation. And this is just for mid size US banking domain. Microsoft Office has to work literally everywhere for everything. The fact that it's on…

Yeah another b(w)anker dev here, complex xsds seem to be the baseline in industry as soon as the role of that spec escapes simple 1 server : 1 client use case.

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.

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

#27
post #11
post #5

> Unfortunately, while an XML schema can be simple, it can also be unnecessarily complex, bloated, convoluted and difficult to implement without specific knowledge of its features. One could now use that exact sentence to describe the most popular open document format of all: HTML and CSS.

Can you be more specific here? HTML and CSS can't be described like that in my opinion. 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…

You could say the existing browser vendors pushed to make the HTML standard more complicated to the point that there's no chance for a newcomer to compete with the existing ones.

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

#28

What we should really do is abandon the WYSIWYG approach to document editing. This inevitably leads into vendor lock in. Instead of perfect looks, we should focus on the content. Formats like markdown are nice, because they force you to do this. The old way made sense 30 yers ago when information was consumed on paper.

Not sure why you're getting so downvoted. It's a totally reasonable opinion in 2025 but it faces massive adoption headwind. People still cling to the idea of printing pages of documents even if it's increasingly rare (even, say in legal) for them to do so.

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

#29
Microsoft is using an artificially complex everything as a lock-in tool. I learned this many years ago when I learned how to create a window in C++ and it took around 100 lines of over-engineered code just to create an empty window on Windows.

Even TypeScript encourages artificial complexity of interfaces and creates lock-in, that's why Microsoft loves it. That's why they made it Turing Complete and why they don't want TypeScript to be made backwards with JavaScript via the type annotations ECMAScript proposal. They want complex interfaces and they want all these complex interfaces to be locked into their tsc compiler which they control.

They love it when junior devs use obscure 'cutting edge' or 'enterprise grade' features of their APIs and disregard the benefits of simplicity and backwards compatibility.

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

#30
post #12

This is a comical perspective to me. I've been ass-deep in core banking APIs where we generate service references from WSDL/XSDs. Some of the resulting codegen measures in the tens of megabytes for some files. I wouldn't even attempt to quantify the number of pages of documentation. And this is just for mid size US banking domain. Microsoft Office has to work literally everywhere for everything. The fact that it's on…

Interfacing sounds like only just half the battle though? Like, I don't understand why this is a counter-argument.
Post reply on HN