Cyrus_the_virus
Unmountable Boot Volume
When MS announced that SP2 for Office 2007 would support ODF and not OOXML, it suffered defeat at its own hands
By Neil McAllister (InfoWorld) 30/05/2008 11:41:18
Score one for the good guys: Last week, Microsoft announced that not only would Office 2007 Service Pack 2 support the ODF (Open Document Format) standard, but the productivity suite would not offer support for the ISO standard version of Microsoft's own OOXML (Office Open XML) format until its next major version, release date unknown.
The move is sure to please some customers, particularly in government agencies in the US and around the world, who have been clamoring for an open, standards-based document format. For Microsoft, however, it should be seen as nothing less than a defeat, after a protracted and often bitter rivalry between the competing document standards.
How could OOXML have gone so wrong? If we take Microsoft at its word that its goals include greater interoperability and transparency, we can only chalk this disaster up to plain blundering. From its inception, OOXML has been a textbook example of how not to develop an open standard.
There are two main ways to fail at the standards game: You can create software that handles documents in formats for which no true standards exist, or you can create a standard that exists only on paper and in committee, with no reference software implementation. Amazingly, for all its hype and bluster, with OOXML Microsoft has managed to do both.
In the course of researching a recent article on next-generation Web technologies, I was given a firsthand look at how healthy standards processes work. Take, for example, Google's efforts to bring new features to the forthcoming version of the HTML standard. It began with Google Gears, a set of plug-ins that adds new capabilities, including local database storage, to the current generation of Web browsers.
"You can take a look at the HTML 5 proposal that's being actively edited at the moment and you'll see that there's a database API like Gears has a database API," Dion Almaer, a developer advocate at Google, told me. "We very much want this to be part of the Web for everybody to use."
Google is actively involved in the HTML 5 committees at the W3C, where it's helping to draft portions of the standard that reflect the Google Gears capabilities. In turn, as the standard evolves, so too will Gears. Compare that to how Microsoft began with closed, proprietary office file formats, then shoehorned them into XML versions that reflected neither prior art nor industry consensus.
Similarly, Adobe has been working to improve ECMAScript, the standard upon which both ActionScript and JavaScript are based. "Programming 'in the large' has been a problem with untyped languages like JavaScript," says Ed Rowe, director of engineering for the Adobe AIR platform. "That's why Adobe has been working with [ECMA] on ECMAScript 4 ... to introduce concepts that are compatible with building large-scale applications."
In essence, the ActionScript 3 engine found in Flash Player 9 is Adobe's implementation of where it believes ECMAScript is headed. By comparison, Microsoft implemented OOXML and then sent it off to committee, where it has since changed and evolved. Now, although Office 2007 claims to support OOXML, its implementation doesn't meet the published standard.
The key point to recognize is that standardization must be a two-way street. Significantly, both Google Gears and Adobe's ECMAScript engine are open source. As a result, there is transparency and accountability for the standards at the implementation level, not just on paper.
"If you look at standards that have been successful versus ones that haven't, in my view, uniformly it's whether or not they've actually been tested or whether they were just a bunch of vendors in a room trying to work out what to do," says Google's Almaer.
Even ignoring the reported voting irregularities in the OOXML standardization process, it's clear that Microsoft's method simply isn't how it's done. By insisting on unilaterally creating the OOXML draft standard, then implementing it with proprietary, closed-source software, it has defeated the transparency it claims to want every step of the way, virtually dooming itself to failure.
But there's one more point to recognize here. For all its success, HTML and its associated languages are hardly the poster children for standards compliance, either. Internet Explorer isn't the only culprit here; Firefox, Safari, and even Opera have all struggled to implement the published standards exactly. Rather than gloat, however, Microsoft should take this point as a lesson: Drafting and implementing a complex standard file format is very, very difficult. In fact, it's far too difficult for even Microsoft to do on its own.
Here's looking forward to Office 2007 Service Pack 2 and ODF.
Source
By Neil McAllister (InfoWorld) 30/05/2008 11:41:18
Score one for the good guys: Last week, Microsoft announced that not only would Office 2007 Service Pack 2 support the ODF (Open Document Format) standard, but the productivity suite would not offer support for the ISO standard version of Microsoft's own OOXML (Office Open XML) format until its next major version, release date unknown.
The move is sure to please some customers, particularly in government agencies in the US and around the world, who have been clamoring for an open, standards-based document format. For Microsoft, however, it should be seen as nothing less than a defeat, after a protracted and often bitter rivalry between the competing document standards.
How could OOXML have gone so wrong? If we take Microsoft at its word that its goals include greater interoperability and transparency, we can only chalk this disaster up to plain blundering. From its inception, OOXML has been a textbook example of how not to develop an open standard.
There are two main ways to fail at the standards game: You can create software that handles documents in formats for which no true standards exist, or you can create a standard that exists only on paper and in committee, with no reference software implementation. Amazingly, for all its hype and bluster, with OOXML Microsoft has managed to do both.
In the course of researching a recent article on next-generation Web technologies, I was given a firsthand look at how healthy standards processes work. Take, for example, Google's efforts to bring new features to the forthcoming version of the HTML standard. It began with Google Gears, a set of plug-ins that adds new capabilities, including local database storage, to the current generation of Web browsers.
"You can take a look at the HTML 5 proposal that's being actively edited at the moment and you'll see that there's a database API like Gears has a database API," Dion Almaer, a developer advocate at Google, told me. "We very much want this to be part of the Web for everybody to use."
Google is actively involved in the HTML 5 committees at the W3C, where it's helping to draft portions of the standard that reflect the Google Gears capabilities. In turn, as the standard evolves, so too will Gears. Compare that to how Microsoft began with closed, proprietary office file formats, then shoehorned them into XML versions that reflected neither prior art nor industry consensus.
Similarly, Adobe has been working to improve ECMAScript, the standard upon which both ActionScript and JavaScript are based. "Programming 'in the large' has been a problem with untyped languages like JavaScript," says Ed Rowe, director of engineering for the Adobe AIR platform. "That's why Adobe has been working with [ECMA] on ECMAScript 4 ... to introduce concepts that are compatible with building large-scale applications."
In essence, the ActionScript 3 engine found in Flash Player 9 is Adobe's implementation of where it believes ECMAScript is headed. By comparison, Microsoft implemented OOXML and then sent it off to committee, where it has since changed and evolved. Now, although Office 2007 claims to support OOXML, its implementation doesn't meet the published standard.
The key point to recognize is that standardization must be a two-way street. Significantly, both Google Gears and Adobe's ECMAScript engine are open source. As a result, there is transparency and accountability for the standards at the implementation level, not just on paper.
"If you look at standards that have been successful versus ones that haven't, in my view, uniformly it's whether or not they've actually been tested or whether they were just a bunch of vendors in a room trying to work out what to do," says Google's Almaer.
Even ignoring the reported voting irregularities in the OOXML standardization process, it's clear that Microsoft's method simply isn't how it's done. By insisting on unilaterally creating the OOXML draft standard, then implementing it with proprietary, closed-source software, it has defeated the transparency it claims to want every step of the way, virtually dooming itself to failure.
But there's one more point to recognize here. For all its success, HTML and its associated languages are hardly the poster children for standards compliance, either. Internet Explorer isn't the only culprit here; Firefox, Safari, and even Opera have all struggled to implement the published standards exactly. Rather than gloat, however, Microsoft should take this point as a lesson: Drafting and implementing a complex standard file format is very, very difficult. In fact, it's far too difficult for even Microsoft to do on its own.
Here's looking forward to Office 2007 Service Pack 2 and ODF.
Source
not even Microsoft knows what changes need to be made. They had to cover this up and take away some attention and they did that by announcing implementation of ODF.
