File format compatibility for common applications such as word
processors and spreadsheets is worthwhile for everyone, whether you're
perfectly happy with Microsoft Office or you're hankering for a freer or more
Web-connected alternative.
After all, the more people who are able to not only consume but
use and participate in the creation of our documents and spreadsheets, the more
valuable those documents can be to us.
Fortunately, the state of file format compatibility across a
range of different applications has come a long way in the past few years, as
vendors have made progress toward addressing the two major pieces of the
compatibility puzzle.
First, while no two applications ever will match up completely
in functionality, applications meant to
interoperate need to provide a core of common features—if there's no analog in
Suite A to your personal favorite Suite B feature, then you can forget about
using the feature in your documents or expecting it to survive any round-trip
editing scenario.
Second, there should be common ways to record the output of
these core features, with standards clear enough—and broadly adopted enough—so
that people can work together from the applications and platforms of their
choice, with documents moving around with relatively little friction.
On the features front, OpenOffice.org has steadily blurred the
lines between itself and Microsoft Office by adding and enhancing core
features. For instance, OpenOffice.org's recent 3.1 release boosts PowerPoint presentation compatibility significantly just by
sharpening the on-screen graphics rendering of Impress.
On the format standardization side, Microsoft's recent Office 2007
SP2 release represents a major step toward bridging file format
compatibility gaps by adding support for OpenOffice.org's default OpenDocument
format. Microsoft's maiden ODF support effort checked out well in the initial
tests I put it through, but significant issues exist in Microsoft's ODF
implementation, such as in its handling of spreadsheet formulas.
Microsoft based its ODF work on current, ISO-blessed
Version 1.1 of the standard, which didn't go far enough in specifying formula
handling to ensure the formulas would work the same as they moved from one
ODF-based spreadsheet application to another.
Microsoft chose to deal with the lack of clarity around
formulas in ODF 1.1 by stripping formulas out of ODF spreadsheets opened in
Excel 2007 SP2. On the positive side, this tactic preserves whatever values
inhabited the spreadsheet's cells when they were last calculated, but that
comes at the cost of being able to use the formulas—a major negative.
ODF adherents are claiming that Microsoft's choices must have
been the result either of incompetence or of ill will, and Microsoft is firing
back with sort of an Eddie Haskell response about sticking to the letter of the
standard.
It might have been helpful if Microsoft had targeted instead
ODF 1.2, which is what OpenOffice.org uses by default (with 1.1 as an option)
and which includes a great deal more detail concerning formulas. It's
understandable, however, that Microsoft would have preferred to target the
current 1.1 standard over the as-yet-unratified Version 1.2.
Alternatively, I would have expected Microsoft to deal with
confusing bits of the ODF specification by referring to existing
implementations. How did OpenOffice.org deal with formulas in ODF 1.1? If
nothing else, I would have liked to see the Excel team provide users with a
pop-up dialog advising that their ODF spreadsheet formulas had been stripped
out.
I intend to judge the success of ODF, and of Microsoft's participation,
by the code that comes out of it. ODF support in Office 2007 SP2 was a
promising start, and I look forward to seeing what bug fixes Microsoft sends
down its patching pipe and what Office 2010 will bring regarding ODF.
Executive Editor Jason
Brooks can be reached at jbrooks@eweek.com.
Enterprise Applications News & Reviews 
