I've heard this comment about OpenXML (the xml format of the office documents) before, and i'm a bit on the fence about it.
It's of course indeed ridiculously complex, but so is office. Microsoft both adds a shit ton of functionality to their documents, and keeps an impressive amount of backwards compatibility.
In the past i heard complaints about part of the OpenXML spec that also allows older binary data in there for backwards compatibility reasons, which of course means for OSS implementations that they don't just have to implement this spec, but also the older spec that came before to be truly compatible with everything a modern office version can open.
But on the other hand, if i look at it from the side of Microsoft, they opened up their format, they've got a gazillion functionalities, should they remove functionality to appease the open source developers? If so which? Should they stop being backwards compatible with documents of decades ago to appease the open source developers? If so how long should they support? Are you going to tell their customers?
Office is an immense program with an immense amount of legacy features, backwards compatibility, ....
It's incredibly complex by nature. And might they have made the format more complex to dissuade competition? Could be. However, in this instance Occam's razor pushes me more to "write a huge program over a timespan of many decades, with thousands upon thousands of programmers working on it, and you'll indeed most likely end up with something very complex...."
Office Open XML was only standardized in order to combat the threat posed by Open Document as organisations were starting to mandate use of standardized formats.
You write as if Microsoft did this because they wanted interoperability, when in reality they only begrudgingly accept that some must be allowed in order to avoid losing control of the market.
The real solution would have been to never approve the OOXML standard and not legitimize Microsoft's attempt to make their proprietary format appear open.
I've heard this comment about OpenXML (the xml format of the office documents) before, and i'm a bit on the fence about it.
It's of course indeed ridiculously complex, but so is office. Microsoft both adds a shit ton of functionality to their documents, and keeps an impressive amount of backwards compatibility.
In the past i heard complaints about part of the OpenXML spec that also allows older binary data in there for backwards compatibility reasons, which of course means for OSS implementations that they don't just have to implement this spec, but also the older spec that came before to be truly compatible with everything a modern office version can open.
But on the other hand, if i look at it from the side of Microsoft, they opened up their format, they've got a gazillion functionalities, should they remove functionality to appease the open source developers? If so which? Should they stop being backwards compatible with documents of decades ago to appease the open source developers? If so how long should they support? Are you going to tell their customers?
Office is an immense program with an immense amount of legacy features, backwards compatibility, ....
It's incredibly complex by nature. And might they have made the format more complex to dissuade competition? Could be. However, in this instance Occam's razor pushes me more to "write a huge program over a timespan of many decades, with thousands upon thousands of programmers working on it, and you'll indeed most likely end up with something very complex...."
Office Open XML was only standardized in order to combat the threat posed by Open Document as organisations were starting to mandate use of standardized formats.
You write as if Microsoft did this because they wanted interoperability, when in reality they only begrudgingly accept that some must be allowed in order to avoid losing control of the market.
The real solution would have been to never approve the OOXML standard and not legitimize Microsoft's attempt to make their proprietary format appear open.