Is OOXML Artifically Complex?
11–20 of 161 posts
Re: Is OOXML Artifically Complex?
#12Earlier quoted context omitted.
I think we take issue with requiring the leap to Microsoft “deliberately” obstructing interoperability. Microsoft just isn’t incentivized to make it simple to implement, but it’s probably less complicated than the various web standards.
An engineering team in Microsoft decides to switch from binary format to XML to save effort in the long run; even though it'll take some effort now, they have the competency, and can afford it. They are absolutely correct! But then their manager needs to sell this project to the higher-ups, who have read BillG's memo about how "One thing we have got to change in our strategy – allowing Office documents to be rendered…
It’s not actually that bad.
Re: Is OOXML Artifically Complex?
#13I once digged through the 5000 page specification. There was a lot of useless stuff that only old Microsoft Word supported like WordArt items.
Re: Is OOXML Artifically Complex?
#14sigh Just because it was not deliberately engineered to be prohitibively expensive to support does not mean that it can not be used to deliberately obstruct interoperability. It's really not that difficult a concept: if you want others to suffer, you can take a sad artifact of well-meant historical accidents, and say "welp, now it's a standard, you gotta support it!" There is nothing contradictory or conspirational.
Agreed. I'm... not entirely clear I get the distinction the article is trying to make?
If you take the idea that it is "artificially complex, because they actively added complexity", then I can see how that isn't quite right. But "artificially complex" can also allow for "because they actively avoided the effort to remove complexity." In which case, we are back to the same spot? But in agreement this time?
Re: Is OOXML Artifically Complex?
#15> Faced with demands for openness, Microsoft could have produced a clean, modern spec and keep the mass pile of legacy inside the application.
Very, very few people care about openness. Maybe a few hundred. Tens of millions care about docx capturing exactly what their doc files had.
Microsoft made the correct choice.
Re: Is OOXML Artifically Complex?
#16My theory (from anecdotal use) is that the OOXML complexity also explains why M365 office implementation is lacking in so many features and is just not very good at all when compared to the Google office suite.
I do have strong memories of OOXML and the scandals that were with it when it became a standard through MS allegedly buying/stacking/influencing votes:
https://chatgpt.com/share/68bf5e11-4e10-8003-ac9d-d4d10f7951...
Re: Is OOXML Artifically Complex?
#17I think the last part is probably the biggest thing holding them back IMO... I tend not to install MS Office products on my personal devices, I haven't run Windows on a personal device in a few years. I've mostly maintained just my resume in word or libre-office format for well over a decade. I can't tell you how many times the LO format lost formatting, or just messed up between version upgrades. Same goes for opening a word version in LO.
That doesn't count the various times where it behaved weird, inconsistently had fields/tables that were impossible to edit, etc. I've had to completely recreate everything a couple times over the years. That's just one document, for one guy that I don't really touch that often.
Say what you will about Firefox vs Chrome in terms of usability, compared to MS Word using LibreOffice is worse than early betas of Netscape Navigator 4.0. It's both impressive and upsetting. OnlyOffice at least looks nicer, even if it doesn't really function any better. MS's online version of Word in the browser operates more consistently than either.
Re: Is OOXML Artifically Complex?
#18The answer: no. OOXML is an extremely detailed spec that lists minute details of the Office documents, with uncountable features. While it could have used some "standard" features, there weren't that many usable standards when OOXML was being developed. In comparison, OASIS OpenDocument spec is horribly ambiguous and has all the same issues (like units not being used consistently). It got better over the years, but i…
There are places where it says the equivalent of "Works the same as Word 95" [3], but does not specify in the specification what that means.
It's essentially a serialization of the binary format to XML.
ODF 1.4 is around 1,100 pages across all 4 parts whereas OOXML is over 6,000.
[1] https://stephesblog.blogs.com/my_weblog/2007/08/microsofts-f...
[2] https://ooxmlisdefectivebydesign.blogspot.com/2007/08/micros...
[3] https://www.robweir.com/blog/2007/01/how-to-hire-guillaume-p...
Re: Is OOXML Artifically Complex?
#19Microsoft just took what they had and directly translated it to XML. It's not intentionally messy, it's just a big corporation with old product acting like it.
This is the God's honest.
I worked on the MS Word core team for a little over three years from 2010-2014, and de-facto owned a significant part of implementing ODF / OOXML Strict support.
The binary format was a liability for Microsoft to begin with, because of decades of cruft lining up with actual memory alignment. During my tenure there I ran into code my GM had written as an intern and was still intact -- he had 20+ years of tenure (mostly on Word) when I joined the team.
The translation of the file format to XML involved a significant amount of performance degradation if you weren't careful. Hundreds of millions of people use the app monthly, and MS still tries to maintain backwards compatibility. Given that open APIs were a relatively late development for the app, I really don't think in the current reality of what's expected by boards of directors for the companies they oversee that _anyone_ would take years to:
a) define a spec that maintained that backwards compatibility
b) reach whatever nebulous simplicity metric today's HN article wants
c) not get whoever greenlit the project fired for taking that many engineering hours for a and b
Re: Is OOXML Artifically Complex?
#20Worth keeping in mind that the native MSO formats were using "structured storage", a horrible binary chunked serialization and metadata format from an era where binary embedding of document streams in other application documents via "Object linking and embedding" (OLE, see also Apple's OpenDoc format) was deemed desirable, with zero consideration given to third-party apps and segment formats tied to C++ data structures. Compared to that, OOXML is still a huge progress, and while it's complex I wouldn't say it's maliciously so.
The Shakespeare example is a good one where the sentence is split into multiple spans to apply style rules yet the bare text content could be extracted by just removing all XML tags. Whereas the ODF variant is actually less recommendable as it relies on an unneccesarily complex formatting and text addressing language on top of XML.
The article says
> Even at a glance [ODF's markup] is more intelligible. Strip the text: namespaces and it’s nearly valid HTML. The only thing that needs explaining is that ODF doesn’t wrap To be with a dedicated “bold” tag. Instead, it applies an auto-style named T1 to a , an act of separating content and presentation that mirrors established web practices.
but this definitely makes things more complex for data exchange compared to OOXML.