101–110 of 131 posts
Does software that produces files have an obligation to provide interoperability?
When they have a monopoly, places like the EU will frown on purposefully breaking compatibility. Its called antitrust.
According to who? With what proof? And how/why do they get to be the arbiters of that?
The opinion in the article misses something fundamental . The complexity is not artificial, it is completely organic and natural . It is incidental complexity born of decades of history, backwards compatibility, lip-service to openness, and regulatory compliance checkbox ticking. It wasn't purposefully added , it just happened . Every large document-based application's file format is like this, no exceptions. As a ra…
What do they expect people to do, remove features in order to support other formats? Users won't like that.
I don't even think it's intentional, they had to come up with a file format which supports all the weird historical artefacts in the various Office tools. They didn't have the luxury to first come up with a clean file format and then write the tools around it. And I bet they didn't switch to XML because it was superior to their old file formats, but simply because of the unbelievable XML hype that existed for a short…
Exactly, there is no need for nefarious intentions, when time constraint et mild incompetence suffice. 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).
it somewhat looks like that, but that old binary format changed with every nth yearly major new version and IMHO it looks like not being far away from a slightly serialized dump of their internal app data structures ;)
but
putting aside that they initially managed to incorrectly implement their own standard OOXML and the mess that "accident" caused
they also did support import and even exports (with limited features) of the Open Document format before even fully supporting OOXML, and even use that as standard save option.... (when edition such a document)
like there really was no technical reason why they couldn't just have adopted the Open Document format, maybe at worst with some "custom" (but open and "standardized" (by MS itself) extensions to it)
MS at the time had all insensitive to comply as bad in faith as they could get away with
and what we saw at that time was looking like exactly that
sure hidden behind "accidents" and incompetence
but lets be honest if a company has all interest and insensitive to make something in bad faith and make it go bad absurdly and then exactly that happens then it's very naive to assume that it was actually accidentally most likely it wasn't
that doesn't mean any programmer sat down and intentional thought about how to make it extra complicated, there is no need for that and that would just be a liability, instead you do bad management decision, like (human) resource starve the team responsible (especially keep you best seniors away), give them all messed up deadlines, give them all messed up requirements you know can't work out. Mess up communication channels. Only give them bad tooling for the task. etc. etc. Most funny thing due to how messy software production often is the engines involved might not even notice ;), means no liability on that side.
HTML?
> 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.
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.
This is a dupe from: https://news.ycombinator.com/item?id=44606646 but I'll repeat what I said over there. I feel qualified to opine on this as both a former power user of Word and someone building a word processor for lawyers from scratch[1]. I've spent hours pouring over both the .doc and OOXML specs and implementing them. There's a pretty obvious journey visible in those specs from 1984 when computers were under p…
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
Does this person not understand XML serializers..?
everything on top of the XML AST is the issue
Earlier quoted context omitted.
Exactly, there is no data provided on why the author believes it is “too complex”, just one random person ranting.
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…
having a lot of intend to keep it complicated and cause vendor locking and comply in bad faith
and this being very easy to archive just by not trying to improve on a status quo and creating a standard where you are the only one to decide what goes in where. Or other simple things like intentionally putting a senior engineer you know tends to painfully overweening things but keep it in a working state, etc. etc. Just by management decisions done in a higher level then the project you can pretty reliable mess up things in various ways as needed pretty reliable as long as you have enough people to choose from.
Does software that produces files have an obligation to provide interoperability?
Earlier quoted context omitted.
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.
This is getting downvoted because it's ludicrous. Users want WYSIWIG - documents that are what appears on the printer page or when people they share the document to open it. "Interoperability" is something technical enthusiasts talk about and not something that users creating documents care about outside of the people they share with seeing exactly what was created.
In other words, fidelity to the printed page isn't really as important or as magical today as it was in 1984.