I have been accused in the past of using a “weight” argument against the Open XML specification because it is several thousand pages long. While some people may think that is cute or funny, it is a real concern and is an obvious problem that programmers recognize. That is, it is hard enough to implement a standard correctly, and one that is that long will be virtually impossible to do right. Mark my words on this and let the buyer beware.
Who will implement Open XML correctly and fully? Maybe some of the mistakes that have been made and are now being written into a so called standard for all to have to implement, but I’m guessing there might be a few other shades of meaning that will not be clear.. Why? Since it is essentially a dump into XML of all the data needed for all the functionality of their Office products and since those products are proprietary, only they will understand any nuances that go beyond the spec. The spec may illuminate
Fully and correctly implementing Open XML will require the cloning of a large portion of Microsoft’s product. Best of luck doing that, especially since they have over a decade head start. Also, since they have avoided using industry standards like SVG and MathML, you’ll have to reimplement Microsoft’s flavor of many things. You had better start now. So therefore I conclude that while Microsoft may end up supporting most of Open XML (and we’ll have to see the final products to see how much and how correctly), other products will likely only end up supporting a subset.
That means that other products and software, in practice, will NOT be able to understand arbitrary Open XML that might be thrown at them. There is just too much. Therefore they will only create a bit that they need and send that off. Send it off to whom? The only software that might understand it, namely Microsoft Office.
So this is how I see this playing out: Open XML will be nearly fully read and written by Microsoft products, but only written in subset form by other software. This means that data in Open XML form will be largely sucked into the Microsoft ecosystem but very little will escape for full and practical use elsewhere.
In my opinion, suggesting “choice” amongand Open XML by governments who are seeking control, true choice, and interoperability is nothing more than maintaining the status quo — a requirement for Microsoft products under the guise of supporting a “standard.”
All standards are not the same and providing support for all standards is not the same. Think about the implications of what is going on here. Open XML is not about interoperability in general, it is about moving or keeping a vendor’s products at the center of a universe. Nice marketing tactic. And that’s what this is about: we hear nice words about “open” and “xml” and “standard” but the reality and problems of producing real implementations are left to technical folk. Listen to what your technical people tell you before you make policy decisions that are not open and not particularly practical.
To be clear, people can choose to implement Open XML or not. I think some will try. Let me know after you do.
Finally, do this little thought experiment: imagine how thick a ream, or 500 sheets of paper is. Double that to get the thickness of a thousand pages, make that 4 times thicker to see how thick 4000 pages is. That’s how many pages were in the last draft of the Open XML spec. How many people will you need to implement that fully and correctly, much less read it? I believe the final version is around six thousand pages (correction?). I think we’re already past feasibility for most people unless you’ve already implemented and debugged the software over a period of years.
- “Interoperability vs. intraoperability: your open choice”
- “The calendar according to Excel, or why Open XML is standardizing mistakes”
- “IBM votes NO on Open XML in ECMA”