Passing the OpenXML standard over to ISO
I've been reading some pretty wild stuff lately in the blogosphere around OpenXML and its submission to ISO. If all the rumors and misinformation that's out there is to be believed:
- Microsoft has somehow found a way around the ISO fast track process, so that a vote on Open XML is due any day now
- Open XML and ODF do the exact same thing (even though the spec for one encompasses about 10 times as much information as the other <g/>)
While I'd like to believe the former so that I could dedicate a larger percentage of my time focusing on building the next version of Office, that's just not the case. We are just at the beginning of the ISO review process, and there is still a ways to go. I'll describe this in greater detail below. And as for the latter, we all know that isn't true. ODF and Open XML have very different design goals, and there is a value in having both. They meet very different customer requirements, which is a fact that IBM is really hoping you don't pay attention to.
Choice is a good thing, and that's what we are trying to promote. I can't believe the pushback we're seeing from IBM in particular around Open XML in ISO. They'd like you to believe they're in favor of all open standards, but the way they're behaving with all the hue and cry, it makes me wonder. I keep dying to ask IBM, "if you really think ODF is the best solution, why does it matter so much if Open XML also co-exists as an ISO standard?What are you afraid of?"
I say we get both formats out there, and have ISO maintain them both so they are guaranteed to be available and maintained long term. This is a good thing because then customers and solution builders can decide for themselves what format meets their needs. OpenOffice is going to support Open XML thanks to Novell, and there will be a free add-on for Microsoft Office that allows it to support ODF.
Usually when you see people pushing really hard to ban something it's out of fear, and unfortunately I think that's what's going on here. I'm starting to understand how artists and authors feel when they have fearful conservative groups try to ban their work. This is something in which I've dedicated the last several years of my life trying to get it right and I want it to be available to everyone. I've talked with enough of you to understand that there are still folks out there who don't trust Microsoft. I hope that we can help change that view, but I know that it takes time, and old skepticisms die hard. That's why I think the best thing is for developers to check out the documentation Ecma created, and the ODF documentation from OASIS, and decide for themselves what format best meets their needs. If that's ODF, great. But really look at the spec before making a decision; I think you'll be impressed by the work that's been done by the technical committee.
IBM has a lot of money in the game banking on ODF, and my guess is that there is a lot of fear on their side that if there are alternatives to ODF they will lose. Hopefully they haven't painted themselves into a corner where they couldn't adjust to customers asking for another format, but I have no clue. From my point of view it's just a file format. If the file format allows you to serve your customers needs, then you're in good shape. And if it doesn't meet your customers' needs, then they won't use it. But trying to prevent choice is just foolish, because customers will go elsewhere when they're not getting what they want.
So what's really going on?
So what's really going on? Well, let me give you a little background into the Fast Track process, and how all this works. I'm actually learning it for the first time myself from my colleagues at Ecma, who are the ones who submitted the formats for ISO consideration (Microsoft submitted the formats to Ecma back in 2005, but it was Ecma that just recently submitted them to ISO).
Processes like fast track exists so that ISO can farm the majority of the standardization work to separate standards organizations like Ecma. This way the work to generate and collaborate on the standard can be fully covered before it's submitted to ISO for a final review. This allows ISO to spend more time focusing on whether or not there are contradictions or serious technical issues that should prevent it from being owned by ISO. This is very similar to what ODF went though. It wasn't called fasttrack, but there was a very similar process that OASIS was able to use when they send ODF through ISO.
This first month in the fast track process is the contradiction period, and the focus is to review the spec and see if there are any contradictions. A contradiction would exist if it turned out that approving Open XML would invalidate another standard. For example, if we had a technology for wireless communication, but in using that technology, it would interfere with folks using another already existing ISO standard, then we'd have a contradiction. OpenXML most likely won't have any contradictions, because with file formats, two can very easily co-exist. Almost every office productivity application out there supports more than one format, which shows they can coexist. For example, ODF doesn't prevent HTML from working, and the same is true for OpenXML and ODF. There is an open source project out there that does translation between the two formats that anyone can view.
After the contradictory period is over, then the technical review begins. So, there will still be at least another 5 months after the contradiction period for technical review, and only after that do the different national bodies submit their yes/no vote.
Why create a new format and standard?
As a bit of a background, the Open XML file formats exist because there was a strong customer demand for them. We wanted to increase the value of the documents the Office creates, and a key way to do that is by opening them up to allow other solutions to interact with them. There were no other file formats out there that could fully represent a Microsoft Office document, so we created our own. We always look around at other technologies to potentially use (like ZIP and XML), but as far as the full end to end solution there wasn't anything (ODF even today is still in its infancy, and couldn't do the job). When looking at ODF, you can see it doesn't even define how to use spreadsheet formulas like =sum(A1:A4); or tables within a presentation. That's an immediate non-starter. There was of course HTML, but we already tried that back in Office 2000. It an excellent format for certain types of documents, but not able to support the full set of features that our customers use for creating their documents. So we created our own format, because if we had tried to use any of the other options, our customers would have just ignored it and continued to use the old binary formats (and that doesn't get us anywhere).
The Open XML format was designed to fully represent all the features in the legacy base of Office documents. This is obviously a big pain when designing a new format, but one we had to take on. Believe me, most of us would have loved to have started from scratch, but in doing so we would risk creating a format that none of our customers would use. So we created the format and ensured that it could fully represent all the existing documents, while still allowing for innovation and extensibility going forward. Some feedback that we got primarily from governments was that they wanted to see these formats not just fully documented, but that the stewardship and maintenance of that documentation should be handed over to an international standards body. They wanted a guarantee that if Microsoft were to disappear tomorrow, or somehow change its mind on the formats, that wouldn't affect the long term availability. They also wanted us to go through an international standards body because that would help provide some objective review of whether or not the formats were interoperable cross platform. So we worked with folks like Apple, Novell, Intel, British Library, Library of Congress, Barclay's Capital, BP, StatOil, etc. to fully work through the spec and ensure it was properly documented and had nothing that would tie to into using another platform. The entire group signed off on this work back in October, and the Ecma general assembly approved it as a standard last month (with only one "no" vote coming from IBM). To give you an example of the type of folks we had working with us on this, the engineers from Novell are significant contributors to the OpenOffice project, so they obviously care a ton about getting a spec that can be used by others.
Why would people want to block access to OpenXML?
Obviously, a great way to guarantee the long term availability of OpenXML, and the confidence that it won't change is for an organization like ISO to take ownership of the spec. We will always have people who are against what we're going, and in this case that's primarily being driven by IBM. They want to guarantee that their format (ODF) is the only one that ISO provides, which is driven by the strategy they've adopted for their products and more importantly their services.
I agree that the spec isn't perfect in terms of a general lowest common denominator format. There are parts of the spec that are a bit of a pain due to backwards compatibility reasons, but those are primarily in very insignificant areas. And if it really is a problem, folks should remember that the Ecma work will continue to go on. We will start working on the next version of the spec soon, and one easy thing we can always do is add more information on what's already there. The more exciting part for us is to work on the new features that should be added though. Remember, the ODF spec is far from complete as well. They are working around the clock to bring the ODF spec closer to alignment with OpenXML in terms of the full support for international documents, spreadsheet formulas, tables in presentations, etc. etc. etc.