Is OOXML Artifically Complex?
1–10 of 161 posts
Re: Is OOXML Artifically Complex?
#2Microsoft 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.
Re: Is OOXML Artifically Complex?
#3Dead on.
Microsoft is just dominant and exporting its 40 year old legacy codebase as a spec. LibreOffice team is frustrated that the for-profit model is beating the OSS model and crying foul over mostly necessary complexity. If LibreOffice started from scratch they’d probably appreciate how much Microsoft serializes because a sufficiently complicated document saved to .docx basically provides a reference implementation.
We do need for-profit alternatives to Word, and I’m working on one in legal.
[edit: I hope to put some real thoughts on this down soon, but most of the wonkiness emanates from evolving functionality and varying trends in best practices over the decades. I’ve implemented a fair bit of the spec here: https://tritium.legal, but most of the hard part is providing for bidi language support, fonts, real-time editing and re-rendering, UI and annotations like spellchecking and grammar, not conforming to the markup spec. Spec conformance is just polish and testing. A performant modern word processor of any spec, however, is a technological achievement on the order of a web browser.]
Re: Is OOXML Artifically Complex?
#4I spent a lot of time last year replicating every valid Excel number format. I've really struggled to find good documentation on the excel format when you really get into the weeds.
The use of namespaces is also incredibly annoying in so far as I can tell in every xml library I can find they really aren't well supported for that "human" readable component.
When you crack open the file it feels like you are going to be able to find everything you need with an xpath like //w:t but none of the xml parsers I've found cope well with the namespaces.
Re: Is OOXML Artifically Complex?
#5sigh 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.
Re: Is OOXML Artifically Complex?
#6The 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 it's still not at all great. And its size is now comparable to OOXML, when all the referenced specs are incorporated.
Re: Is OOXML Artifically Complex?
#7sigh 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.
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.
Re: Is OOXML Artifically Complex?
#8Re: Is OOXML Artifically Complex?
#9I spent a lot of time last year replicating every valid Excel number format. I've really struggled to find good documentation on the excel format when you really get into the weeds. The use of namespaces is also incredibly annoying in so far as I can tell in every xml library I can find they really aren't well supported for that "human" readable component. When you crack open the file it feels like you are going to b…
What language?
In Python, the `find`, `findall`, etc. methods take a namespace dictionary. E.g.
result = doc.findall("//w:t", namespaces={"w": "..."})
var navigator = doc.Root!.CreateNavigator();
nsManager = new XmlNamespaceManager(navigator.NameTable);
nsManager.AddNamespace("w", "...");
var results = doc.Root?.XPathSelectElements("//w:t", nsManager);
Re: Is OOXML Artifically Complex?
#10sigh 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.
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 very well by other people's browsers is one of the most destructive things we could do to the company. We have to stop putting any effort into this and make sure that Office documents very well depend on proprietary IE capabilities. Anything else is suicide for our platform. This is a case where Office has to avoid doing something to destroy Windows." and took it to heart. So what does he do? Why, he spins a tale that since it's XML, they'll be able to standardize it, and everyone else will still be forced to interoperate with MS Office anyhow, because it will be the de-facto reference implementation (by the virtue of being there first, and widely deployed), and the spec is going to be an absolute PITA to implement decently — and that manager too will be absolutely correct!