Microsoft steps up to the task at hand

by jlundstocholm 22. May 2008 06:26

Some quite extraordinary news emerged from the Redmond, WA, headquarters of Microsoft today. In summary, they announced that

  1. Microsoft will join OASIS ODF TC
  2. Microsoft will include ODF in their list of specifications covered by the Open Specification Promise (OSP)
  3. Microsoft will include full, native support for ODF 1.1 in Microsoft Office 14 and in Microsoft Office 12 SP2 - scheduled for Q2 2009. Microsoft Office 12 SP" will have built-in support for the three most widely used ISO-standards for document formats, e.g. OOXML, ODF and PDF.


My initial reaction when I heard it was "Wow . that's amazing". I am sure a lot of people will react "It's too little, too late", though, but let me use a couple of bytes to describe why I think it is a good move by Microsoft.

Microsoft joins OASIS ODF TC

Well, Microsoft has been widely criticised for not joining OASIS a few years ago. I think it is a bogus claim, but never the less; it has been on the minds of quite a lot of people. Novell has had a seat in both ECMA TC45 and OASIS ODF TC for some time now, and it is my firm belief that both consortia has benefited by this. The move by Microsoft to join OASIS ODF TC will likely have a similar effect. One of the most frequent requests in the standardisation of OOXML was to increase the feature-overlap of ODF and OOXML. This is quite difficult to accomplish (effectively) without knowing what the features of the other document format is (going to be). By Microsoft participating on both committees (and IBM will hopefully consider joining ECMA TC45) harmonization (or "enlargement of the feature-overlap") will likely occur at a quicker pace.

This also means that the worries some of us have had about Microsoft's future involvement in standardisation work around document formats has been toned down a bit. Microsoft is now actively participating in this work in ECMA, in ISO and also in OASIS. I think this is really good news. Not good news for Microsoft - but good news for those of us that are working with document formats every day.

Microsoft will cover ODF with OSP

One of the most difficult, non-technical, discussions during the standardisation of OOXML was legal aspects. It was discussions about different wordings in Sun's CNS, IBM's ISP and Microsoft's OSP (Jesus Christ, guys, pick ONE single acronym, already!) and the possible impact on implementers of ODF and OOXML. One of the aspects of the discussion that never really surfaced was that if IBM has software patents covering ODF - some of them quite possibly cover parts of OOXML as well. But the ISP of IBM does not mention OOXML - it only mentions ODF. This leaves me as a developer in quite a legal pickle, because by implementing OOXML I am covered by the OSP - but I am not covered by IBM's ISP (and vice versa). To me as a developer, Microsoft's coverage of ODF in their OSP is a good move, because it should remove all legal worries I might have around stepping into SW-patent covered territory.

ODF support in Microsoft Office

Microsoft will finally deliver on requests for native ODF-support for ODF in Microsoft Office. Microsoft will support ODF 1.1 in Microsoft Office 12 SP2 and also have built-in support for PDF and XPS (these are currently only available as a separate download).

Denmark is one of the countries where both ODF and OOXML have been approved for usage in the public sector. This is currently bringing quite a bit of complexity to the daily work of information workers since there are not many (if any) applications offering high fidelity, native support for both formats. They hence rely on translators like ODF-Converter or similar XSLT-based translators. It's a bad, but currently necessary, choice. The usage of translators for document conversion has been widely criticised, amongst others by Rob and I, and the built-in support for ODF in Microsoft Office is a great step in the right direction.

As with everything Microsoft does, we need a healthy amount of scepticism as to which extend they will deliver on their promises. However, I truly believe that the moves by Microsoft here are good news - regardless of the scepticism. An old proverb says "don't count your chickens before they hatch" - and this applies perfectly here. We will have to wait and see what will eventually happen - but so far . it looks good.

Comments

5/22/2008 1:45:53 PM #

pingback

Pingback from osrin.net

More Interop for Microsoft Office (ODF, PDF, PDF/A, XPS) : Oliver Bell’s weblog

osrin.net |

5/23/2008 7:31:47 AM #

esni

[quote]
As with everything Microsoft does, we need a healthy amount of scepticism as to which extend they will deliver on their promises. However, I truly believe that the moves by Microsoft here are good news - regardless of the scepticism. An old proverb says "don't count your chickens before they hatch" - and this applies perfectly here. We will have to wait and see what will eventually happen - but so far . it looks good.

[quote]

Back when the fight was WP5.1 (or WP 6) vs winword 6 Microsoft had designed a very good import filter for WP documents, but export was much less useful. At the time it was generally believed to be out of spite, but I now realize it might at least partly have been because of the very different document models.

The oddest part is really that apparently gives priority to OASIS ODF1.1 over ISO-OOXML, at least if Office12 SP2 arrives before Office 14, as it is expected to.

/esni

esni |

5/23/2008 5:17:52 PM #

jlundstocholm

Hi Eskild,

The oddest part is really that apparently gives priority to OASIS ODF1.1 over ISO-OOXML, at least if Office12 SP2 arrives before Office 14, as it is expected to.
There could be a lot of reasons for this apparent priority to ODF 1.1. A few of these could be

1. Microsoft has been working on ODF-support for quite some time now
2. Even though the changes from the BRM are in some respect relatively minor, they could mean quite substantial changes in the Microsoft Office 12 code. I think it would be a relatively low-impact task to implement OOXML in transistional mode, but certainly not in strict mode.
3. Financial aspects as well, of course.
4. As Alex Brown pointed out, the discrepancy between ISO-OOXML in transitional mode and ECMA-376 are quite small. Maybe Microsoft decided to make an "OpenOffice.org"-move and not produce 100% conformant ISO-OOXML.
5. I would also think it would be relatively easier to implement support for a new document format and extend the internal object model to support it rather than to make drastical changes and modify the existing internal object model to support that.

jlundstocholm Denmark |

5/25/2008 5:52:27 PM #

hAl

It will take quite a while for MS OFfice to produce decent ODF.
OpenOffice is working on it for 5 years and their ODF implementation is far from complete.

hAl |

5/26/2008 10:14:29 PM #

jlundstocholm

hAl,

I don't think we should expect nothing less than a "good implementation" of ODF from Microsoft. A company of their size should have no problems implementing ODF - just as  companies like Google, IBM and OpenOffice.org-organisation should have no problems implementing OOXML. Starting at this early point to talk about "it is ok for Microsoft to implement a poor support for ODF since it has taken 5 yeasrs for OOo to do the same" is asking for trouble.

What will be interesting, though, is how Microsoft is going to use section 2.4 of ODF.

2.4 Application Settings

Will they use the OpenOffice.org/IBM Symphony-approach or will they use a more "pure" approach and not support anything not directly supported by ODF (in fear of being accused of embrace-extend-extinguish an ODF-hijacking)?

How will they implement "document protection" and the other un-specified parts of ODF (like spreadsheet formulas)?

jlundstocholm Denmark |

Comments are closed