There’s starting to be a real buzz if not shock about the latest draft of the so called ECMA “open XML” spec weighing in at a hefty 4081 pages. If you do take a look at it, be prepared to wait a while because the PDF is 24.4 Mb in size. Broadband required.
These numbers alone should be enough to make the point that there will be very few perfect complete implementations, if any. It’s also a measurement of just how bloated with features any software that implements it would have to be. Bear in mind that I said “bloat” and not “wonderfully featureful.” Is this real evidence of why people are moving to more elegant “keep it simple” solutions? Maybeneeds this to cover everything they have ever thrown into their proprietary products. Maybe the rest of us don’t.
For comparison, the OpenDocument Format standard from OASIS is 706 pages (3Mb PDF).
Now we have to be careful with numbers and not simply say that one or the other spec is simply better because it is bigger or smaller. That said, I think looking at the specs will show you that the ECMA spec is much, much bigger than. Simply arguing that bigger is better is wrong here because if “bigger” means “with a lot of features you won’t use” then that’s not of value. Conversely, “smaller” is not instantly better if it means “missing what you need.” ODF is evolving to add a few more features and there is an active multi-vendor open effort going on in working on this. I compare this to going to the gym and working out to build muscle tone and bulk up a little bit. Conversely again (which means we’re back to the ECMA spec), weighing in at 4081 pages means you went to the gym and you swallowed a few treadmills. I’m being facetious, but you get the point.
Here I was going to give some page counts of some standards that are in broad use such as XML and HTML. As I looked at them, two things became clear:
- They are relatively small. Many of them are around a hundred pages though some are bigger. The HTML 4.01 spec is 389 pages in PDF form.
- They are broken down into components that are meant to be used together, and the components are each standardized. Often different people worked on the individual pieces because they have different areas of expertise. The collection fits together as a whole. This means that you are building composable, factored standards rather than a monolithic monster. That generally means better design.
One of our explicit design points with the web services standards was that they should be composable. You don’t have to use them all every time you want to have any web services functionality. You can argue about REST or you can argue about WS-* proliferation, but not one of those specs is 4081 pages long.
So how would you design a good and elegant office standard to meet the needs of what we do now? You would start by thinking about what features people really need. Then you would try to figure out how you maximally take advantage of open standards already created rather than reinventing the wheel or using proprietary techniques. That is, you would develop something that very much resembles ODF.
Given all this and the type of open activity that surrounds it, I think ODF, the OpenDocument Format, represents the future of office documents and it is an international standard today. I strongly suspect the ECMA spec represents the past and its heft will prevent much varied use in times to come. Personally, I vote for a future-ready standard and standards effort, i.e., ODF.