Cyrus_the_virus
Unmountable Boot Volume
Wednesday, May 21 2008 @ 09:29 AM PDT
Contributed by: Admin
Views: 755
*www.consortiuminfo.org/standardsblog/images/icons/ODF.pngMicrosoft today announced that it would update Office 2007 to natively support ODF 1.1, but not to implement its own OOXML format. Moreover, it would also join both the OASIS working group as well as the ISO/IEC JTC1 working group that has control of the ISO/IEC version of ODF. Implementation of DIS 29500, the ISO/IEC JTC 1 version of OOXML that has still not been publicly released will await the release of Office 14, the ship date of which remains unannounced.
The same announcement reveals that Office 2007 will also support PDF 1.1, PDF/A and Microsoft's competing fixed-text format, called XML Paper Specification. XML Paper Specification is currently being prepared by Ecma for submission to ISO/IEC under the same PAS process by which OOXML had been submitted for consideration and approval.
Yesterday afternoon was when I first began to hear news through the grapevine that Microsoft's Jason Matusow (director of corporate standards) and Doug Mahugh (senior product manager for Microsoft Office) would announce native support of ODF. later in the day, I started to get email from journalists who had been alerted that Microsoft would make a format-related announcement, and were trying to figure out what it would say. Now that the announcement has been made and first press reports are beginning to surface, there are even more questions that there were yesterday. In this blog entry I'll review what has been said, what has not, and what questions remain.
The first reporter to break the story, according to a Google search, was David Worthington, writing for Software Developer Times. Worthington also reported that Microsoft will also join ISO Technical Committee 171, the working group responsible for PDF, and also offer an API that developers can use to develop Office plug in converters that would permit users to select another that format, such as ODF, as their desired default save format.
The story also includes quotes from Matusow and Mahugh that provide intriguing incites to how the decisions were made. After noting that saving to the OASIS ODF 1.1 format would now be possible, Worthington writes:
“Customers that are expecting true document fidelity from XML-based, ISO-standard document formats will continue to be disappointed." Silver observed that the most compatible formats to use today are Microsoft’s legacy binaries, and he believes that Microsoft will be unlikely to convince customers to move to OOXML in the foreseeable future.
So what exactly does this all mean? First, let's start with what we still don't know.
When will the ODF feature be available? We don't know. I've heard through the grapevine that we might be looking at 6 - 9 months. A formal planned ship date would obviously be useful to receive.
What will the source of the function be? There are two obvious sources. One would be the CleverAge open source project conversion code generated by the long-running project at Source Forge funded by Microsoft. The other would be internal development. While either is possible, in comparing notes with others there are indications that development work may have been ongoing for some time to enable this function.
Under what terms will the API be made available? Until Microsoft announces to the contrary, the most logical assumption would be Microsoft's existing Open Specification Promise (OSP). That commitment is fine for proprietary vendors and non-commercial open source use, but incompatible with commercial open source products.
Finally, and most intriguingly, Why has this announcement been made now? Clearly, Microsoft could have provided native support at any time over the last several years. Office already supports dozens of formats, and the development work for a company of Microsoft's size would be trivial. Until now, avoiding native support has helped limit the spread of ODF-compliant products, due to the fact that documents created using such products could not as easily be exchanged with ubiquitous Office users. And while several plugins have been available for some time, adding them requires effort to locate, download, configure and then train. Individual users are not likely to go to the bother (or may not be sophisticated enough to do so), and enterprise CIOs have more than enough to already, and would be unlikely to until a critical mass of requests for ODF capability had built up.
Once Office users can easily open, edit and reexport files that were originally created in ODF, however, there will be less business and social pressure against creating such files. Given the quality of open source office suites such as OpenOffice, the long-delayed advent of Linux on the desktop, support for ODF in other products such as WordPerfect, and government and open source community enthusiasm for ODF-compliant products, the frequency of ODF-based files popping up in the work flows of Office-based shops can now be expected to increase much more quickly.
So that still leaves the question, why now, especially since ISO/IEC JTC1 is one formality step away from adopting OOXML as DIS 29500? Here's where the other part of the announcement comes in: Microsoft has decided that it will not attempt to implement DIS 29500 until Office 14, the arrival date for which remains in (at least public) limbo. What to do, then, about government customers that require an ISO/IEC approved product?
That's a problem, because even though Alex Brown, the Convenor of the Ballot Resolution Meeting for OOXML in Geneva in February, confirmed yesterday that Ecma delivered a revised specification to ISO on time on March 29, that draft remains closeted behind doors, despite the fact that not only has the final voting period expired (at the end of March), but even the two month appeal period is rapidly reaching a close - this despite a requirement under the applicable Directives that its release to National Bodies should have occurred weeks ago. Until the final draft is finalized and released, final programming work cannot be done to implement it.
So what can Microsoft do to meet its customers' requirements? Notwithstanding the pedal to the floor pressure to push OOXML through the formal standards approval process, Microsoft is left without the actual ability to deliver a product that complies with an ISO/IEC-approved version OOXML for the indefinite future. Moreover, investigations by the European Commission are continuing regarding Microsoft's practices, including its conduct during the adoption of OOXML.
The most it can do, therefore, is to provide native support to that other format - ODF. A silver lining is that any added appeal for Office 2007 will provide a welcome boost for a product that continues to lag Microsoft's originally projected sales.
One possible flaw in the above reasoning is the fact that Microsoft has announced that it will support ODF 1.1, the current OASIS version, rather than DIS 26300, the ISO-adopted specification based on OASIS ODF 1.0. Presumably this is a reflection of the fact that ODF 1.1 will be the foundation for the next version of the ISO standard, as well as the practical reality that all other ODF products in the marketplace will be built to 1.1, due to the additional functionality that it supports. Presumably government users will be more interested in the most useful products available, rather than those that are limited by the constraints of an already dated standards release. Suddenly, it appears, Microsoft has found that indeed its customers really do want usseful native ODF support - something that it had steadfastlly denied for years.
If there is a particular reason to be unhappy with this announcement, based on the limited facts available so far, it would seem to be Microsoft's refusal to implement "save to ODF" as a default option. That will still require either a few extra strokes every time a user saves a document, or installation of a plugin. And, perhaps more as a matter of consistency with other positions it has taken than to reap any real market advantages, such a plug may not be able to be created under the GPL.
All of which, for now, must remain on the "wait and see" list. Here's what to watch for in the months ahead:
1. A release date for the service pack with ODF support and for the API.
2. Whether the API will be available as open source
3. More specifically, whether the API can be used in GPL situation
4. Reviews of how good a job the upgraded suite does in round tripping ODF-generated documents of all types (text, spreadsheet and presentation).
That's all for now. I'll update this entry as further facts become available.
Contributed by: Admin
Views: 755
*www.consortiuminfo.org/standardsblog/images/icons/ODF.pngMicrosoft today announced that it would update Office 2007 to natively support ODF 1.1, but not to implement its own OOXML format. Moreover, it would also join both the OASIS working group as well as the ISO/IEC JTC1 working group that has control of the ISO/IEC version of ODF. Implementation of DIS 29500, the ISO/IEC JTC 1 version of OOXML that has still not been publicly released will await the release of Office 14, the ship date of which remains unannounced.
The same announcement reveals that Office 2007 will also support PDF 1.1, PDF/A and Microsoft's competing fixed-text format, called XML Paper Specification. XML Paper Specification is currently being prepared by Ecma for submission to ISO/IEC under the same PAS process by which OOXML had been submitted for consideration and approval.
Yesterday afternoon was when I first began to hear news through the grapevine that Microsoft's Jason Matusow (director of corporate standards) and Doug Mahugh (senior product manager for Microsoft Office) would announce native support of ODF. later in the day, I started to get email from journalists who had been alerted that Microsoft would make a format-related announcement, and were trying to figure out what it would say. Now that the announcement has been made and first press reports are beginning to surface, there are even more questions that there were yesterday. In this blog entry I'll review what has been said, what has not, and what questions remain.
The first reporter to break the story, according to a Google search, was David Worthington, writing for Software Developer Times. Worthington also reported that Microsoft will also join ISO Technical Committee 171, the working group responsible for PDF, and also offer an API that developers can use to develop Office plug in converters that would permit users to select another that format, such as ODF, as their desired default save format.
The story also includes quotes from Matusow and Mahugh that provide intriguing incites to how the decisions were made. After noting that saving to the OASIS ODF 1.1 format would now be possible, Worthington writes:
However, the company is not quick to embrace its own creation. Mahugh stated that Microsoft would not implement the final ISO version of OOXML until Office 14 ships at an unstated date in the future. This variant of OOXML was designated ISO/IEC 29500 at the time it was certified as an ISO International standard in April.
“One way to look at it is the prioritization of formats,” Mahugh explained. “We reach a point in time where we have to decide whether to continue to invest in a previous version [of Office] or to cut the cord and move forward.”
ODF support was a priority for Microsoft, Mahugh noted, adding that “real world” customers say that there is a pressing need for PDF [AU: ODF?] support. “At this point there are no products using [ISO/IEC 29500] in the marketplace.”
When will Microsoft support its own file format? No release date for Office 14 has been been announced. Worthingon quotes Garter Research's Michael Silver on that score as follows:“One way to look at it is the prioritization of formats,” Mahugh explained. “We reach a point in time where we have to decide whether to continue to invest in a previous version [of Office] or to cut the cord and move forward.”
ODF support was a priority for Microsoft, Mahugh noted, adding that “real world” customers say that there is a pressing need for PDF [AU: ODF?] support. “At this point there are no products using [ISO/IEC 29500] in the marketplace.”
“Customers that are expecting true document fidelity from XML-based, ISO-standard document formats will continue to be disappointed." Silver observed that the most compatible formats to use today are Microsoft’s legacy binaries, and he believes that Microsoft will be unlikely to convince customers to move to OOXML in the foreseeable future.
So what exactly does this all mean? First, let's start with what we still don't know.
When will the ODF feature be available? We don't know. I've heard through the grapevine that we might be looking at 6 - 9 months. A formal planned ship date would obviously be useful to receive.
What will the source of the function be? There are two obvious sources. One would be the CleverAge open source project conversion code generated by the long-running project at Source Forge funded by Microsoft. The other would be internal development. While either is possible, in comparing notes with others there are indications that development work may have been ongoing for some time to enable this function.
Under what terms will the API be made available? Until Microsoft announces to the contrary, the most logical assumption would be Microsoft's existing Open Specification Promise (OSP). That commitment is fine for proprietary vendors and non-commercial open source use, but incompatible with commercial open source products.
Finally, and most intriguingly, Why has this announcement been made now? Clearly, Microsoft could have provided native support at any time over the last several years. Office already supports dozens of formats, and the development work for a company of Microsoft's size would be trivial. Until now, avoiding native support has helped limit the spread of ODF-compliant products, due to the fact that documents created using such products could not as easily be exchanged with ubiquitous Office users. And while several plugins have been available for some time, adding them requires effort to locate, download, configure and then train. Individual users are not likely to go to the bother (or may not be sophisticated enough to do so), and enterprise CIOs have more than enough to already, and would be unlikely to until a critical mass of requests for ODF capability had built up.
Once Office users can easily open, edit and reexport files that were originally created in ODF, however, there will be less business and social pressure against creating such files. Given the quality of open source office suites such as OpenOffice, the long-delayed advent of Linux on the desktop, support for ODF in other products such as WordPerfect, and government and open source community enthusiasm for ODF-compliant products, the frequency of ODF-based files popping up in the work flows of Office-based shops can now be expected to increase much more quickly.
So that still leaves the question, why now, especially since ISO/IEC JTC1 is one formality step away from adopting OOXML as DIS 29500? Here's where the other part of the announcement comes in: Microsoft has decided that it will not attempt to implement DIS 29500 until Office 14, the arrival date for which remains in (at least public) limbo. What to do, then, about government customers that require an ISO/IEC approved product?
That's a problem, because even though Alex Brown, the Convenor of the Ballot Resolution Meeting for OOXML in Geneva in February, confirmed yesterday that Ecma delivered a revised specification to ISO on time on March 29, that draft remains closeted behind doors, despite the fact that not only has the final voting period expired (at the end of March), but even the two month appeal period is rapidly reaching a close - this despite a requirement under the applicable Directives that its release to National Bodies should have occurred weeks ago. Until the final draft is finalized and released, final programming work cannot be done to implement it.
So what can Microsoft do to meet its customers' requirements? Notwithstanding the pedal to the floor pressure to push OOXML through the formal standards approval process, Microsoft is left without the actual ability to deliver a product that complies with an ISO/IEC-approved version OOXML for the indefinite future. Moreover, investigations by the European Commission are continuing regarding Microsoft's practices, including its conduct during the adoption of OOXML.
The most it can do, therefore, is to provide native support to that other format - ODF. A silver lining is that any added appeal for Office 2007 will provide a welcome boost for a product that continues to lag Microsoft's originally projected sales.
One possible flaw in the above reasoning is the fact that Microsoft has announced that it will support ODF 1.1, the current OASIS version, rather than DIS 26300, the ISO-adopted specification based on OASIS ODF 1.0. Presumably this is a reflection of the fact that ODF 1.1 will be the foundation for the next version of the ISO standard, as well as the practical reality that all other ODF products in the marketplace will be built to 1.1, due to the additional functionality that it supports. Presumably government users will be more interested in the most useful products available, rather than those that are limited by the constraints of an already dated standards release. Suddenly, it appears, Microsoft has found that indeed its customers really do want usseful native ODF support - something that it had steadfastlly denied for years.
If there is a particular reason to be unhappy with this announcement, based on the limited facts available so far, it would seem to be Microsoft's refusal to implement "save to ODF" as a default option. That will still require either a few extra strokes every time a user saves a document, or installation of a plugin. And, perhaps more as a matter of consistency with other positions it has taken than to reap any real market advantages, such a plug may not be able to be created under the GPL.
Update: Kevin J. O'Brien, reporting in the International Herald Tribune, reportst that the ODF update will permit users to "adjust Office 2007 settings to automatically save documents in the rival format." A knowledgeable source tells me that this report is likely to be accurate.
Regardless of the motivation, today's announcement is indeed good news for everyone that believes in open document formats in general, and in ODF in particular. Once Office users can round trip documents with ODF users, and vice versa, the frequency of that process should begin to increase. Hopefully, Microsoft's years-long delay in agreeing to participate in the ODF working group will allow better interoperability as well over time.
All of which, for now, must remain on the "wait and see" list. Here's what to watch for in the months ahead:
1. A release date for the service pack with ODF support and for the API.
2. Whether the API will be available as open source
3. More specifically, whether the API can be used in GPL situation
4. Reviews of how good a job the upgraded suite does in round tripping ODF-generated documents of all types (text, spreadsheet and presentation).
That's all for now. I'll update this entry as further facts become available.
For further blog entries on ODF and OOXML, click here
Source
you need to learn to live with it 