As opposed to the original binary format, designed to copy directly to the heap on restore?
Microsoft Office is using an artificially complex XML schema as a lock-in tool
71–80 of 131 posts
Re: Microsoft Office is using an artificially complex XML schema as a lock-in tool
#72I wish this article had shown side-by-side examples. Back when I built document transformation tools as part of a publishing pipeline, the simplicity and clarity benefit of OpenDocument's XML over Microsoft's OOXML were *staggering* in practice. A beautiful, clean, logical approach vs beyond-Byzantine cruft and complexity at every turn. I don't remember every element enough to render from memory, but ChatGPT's exampl…
By accident, I saw firsthand how a simple layout, such as a page and a few paragraphs, can make you question why formats like Markdown are even possible, because the number one text processing tool would throw such a gigantuan load of crude syntax at you for a few paragraphs.
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.
Re: Microsoft Office is using an artificially complex XML schema as a lock-in tool
#73Earlier quoted context omitted.
Interfacing sounds like only just half the battle though? Like, I don't understand why this is a counter-argument.
As argued elsewhere in this thread there is essential complexity inherent to any problem that cannot be eliminated. https://news.ycombinator.com/item?id=44613270 If you have this much complexity and there is nothing you can do to reduce it , then the next best thing is to have an incredibly convenient way to stand up a perfect client on the other side of the fence within a single business day.
It's not that I agree with the characterization in the OP, that these formats are deliberately obtuse. It's that I do agree about them being obtuse, and that being able to say that you can auto-generate bindings for them doesn't actually help to make them not obtuse.
I do also think that Office should have created separate formats for project files and export files; if an RTF can hold onto all the formatting details of a typical Word document sufficient for pixel-accurately rendering it for example, then they should have conveyed that better and promoted it as the default export format (along with the idea of an export format), rather than immediately hitting people with a popup that claims their data will be partially lost. If this does exist (just not as an RTF), this point still stands - I don't use it, nobody I know uses it, so it may as well not exist.
Current state of affairs is people passing around docx, xlsx, etc. files, which are project files, hence why they (have to) contain (fancifully) serialized application state. Imagine if people passed around PSDs rather than PNGs. Or if people passed around FLPs rather than WAVs, FLACs or MP3s. It's this separation between the features of a document / spreadsheet / presentation and the features of the authoring software that appears to be completely absent from Microsoft Office, and this is something that just based on the information I have available, MS can legitimately be faulted for. Transitioning from a bespoke binary format to an XML based format with schemas available did basically nothing to help this.
And while it might seem like that I'm suggesting that export formats are this cleanly definable, self-evident things, I don't actually mean to suggest so either. It'd have had to have been a business decision. To where to draw the line would have been a decision that apparently never came to be debated internally, from what anyone can currently tell in retrospect at least, from the outside.
Re: Microsoft Office is using an artificially complex XML schema as a lock-in tool
#74What 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.
This could only work if all people using computers are tech people, and willing to spend a couple of months learning latex or whatever. None of the two conditions are reality, of course. So yeah, that’s not happening.
[deleted]
Re: Microsoft Office is using an artificially complex XML schema as a lock-in tool
#75Earlier quoted context omitted.
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.
Sure, technical documents are long but that still doesn’t support the original claim that they are “unnecessarily complex, bloated, convoluted” and it’s actually evidence against the assertion that they’re “difficult to implement without specific knowledge of its features”: most of why those are long documents is that they carefully detail how necessarily complex systems interact in sufficient detail to implement them whereas the Office XML specs at least historically had things like flags telling to behave like, say, Word95 without fully specifying the behaviour in question.
Re: Microsoft Office is using an artificially complex XML schema as a lock-in tool
#76I think the lock-in is more about MSFT's contracts with schools, governments and corporations. I wish they break large corporations to pieces.
Re: Microsoft Office is using an artificially complex XML schema as a lock-in tool
#77HTML?
Re: Microsoft Office is using an artificially complex XML schema as a lock-in tool
#78Earlier quoted context omitted.
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.
Sure, technical documents are long but that still doesn’t support the original claim that they are “unnecessarily complex, bloated, convoluted” and it’s actually evidence against the assertion that they’re “difficult to implement without specific knowledge of its features”: most of why those are long documents is that they carefully detail how necessarily complex systems interact in sufficient detail to implement the…
The original claim was clearly actually just an opinion; I don't think there's merit to treating it as a series of logical statements, or at intricate depth in general.
Evidence for this is in the very words used: unnecessary, complex, bloated, convoluted. These are very human terms that are thus subject to personal interpretation and opinions.
It shouldn't be surprising then that their "claim" thus fails scrutiny. All they actually meant to say is that HTML and CSS are both verbose standards with a lot of particularities - still something subjective, but I think page / word / character counts are pretty agreeable attributes to estimate this with in an objective way. Hence why I brought those up exactly.
Re: Microsoft Office is using an artificially complex XML schema as a lock-in tool
#79I 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…
Sorry but XML is a good fit for this. Most people who've never used XML cannot ever fathom that it does actually do a number of things well. 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 t…
There are good use cases for XML.
There was also huge hype. XML databases, anyone? XML is now an also-ran next to json, yaml, markdown. At the time, it was XML all the things!
Re: Microsoft Office is using an artificially complex XML schema as a lock-in tool
#80The 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…
You might start with something simple with aim for simplicity. Then you need to add more features. Eventually in enough years you will have lost the simplicity as you have that many features to support. 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 lin…
Everyone uses 10% of the features of complex software... it's just not the same 10%, which is why the other 90% needs to be in there and included in the file formats.
It's also not sufficient to find that "perfect" lean and mean application that happens to cover precisely the 10% that you need for yourself, because now you can't interchange content with other people that need different features!
I regularly open and edit Office documents created by others that utilise features I had never even heard of. I didn't know until very recently that Power Point has extensive animation support, or that Excel embeds Python, or that both it and Power BI can reach out to OData API endspoints to refresh data tables or even ingest Parquet directly.
You might not need that, but the guy that prepared the report for you needed it.