Office 2007SP2 ODF Interoperability Very Bad 627
David Gerard writes "Microsoft Office 2007 SP2 claims support for ODF 1.1. With hard work and careful thinking, they have successfully achieved technical compliance but zero interoperability! MSO 2007sp2 won't read ODF 1.1 from any other existing application, and its ODF is only readable by the CleverAge plugin. The post goes into detail as to how it manages this so thoroughly."
Sun ODF plugin for Microsoft Office (Score:5, Informative)
Re:Everybody pile on Microsoft... (Score:5, Informative)
this is how [wikipedia.org]
Kind of looks like the whole thing was a farce to begin with given how they created a bad spec and then went on to support a worse one before imploding.
Re:They also claim Windows supports Posix (Score:5, Informative)
Microsoft Windows is POSIX.1 compliant, which will not help anyone today but which is nonetheless true.
The problem is formulas. (Score:5, Informative)
ODF does not specify the a language for formulas. Everybody but MS uses one language, MS uses another. Of course there are incompatibilities.
Why did ODF not specify a spreadsheet formula language?
Re:What did we expect? (Score:5, Informative)
And the problem in this case is the missing formula specification. It's not in ODF 1.1, and ODF 1.2 is still a draft. While this is Microsoft and we all "know" that this was intentional, ODF is what should be fixed first. We were all bashing OOXML specifications, but ODF 1.1's far from perfect, as we can see.
That is, curiously, not quite true. ODF 1.1 doesn't fully specify formulas, but it does specify the general syntax that should be used for them, and Microsoft seems to have ignored this. (Also, in practice, the major spreadsheets are quite similar in terms of what expressions they accept in formulas. This makes it relatively simple to convert between MS Office formulas and OpenOffice.org ones, which are what most ODF-based apps use.)
Re:Everybody pile on Microsoft... (Score:3, Informative)
Re:What did we expect? (Score:5, Informative)
nobody would have believed that Microsoft was the good guys.
Actually there was a time when Microsoft was hailed as the white knight in the shiny armor freeing us from the evil IBM empire.
Re:They also claim Windows supports Posix (Score:5, Informative)
Well if you just go for the basic level of posix support, then yes it does support it. So does 100 other OSes, including weird embedded OSes that can't even run executables. Everything has to be compiled in, but they are "POSIX" too.
To be far UNIX Services for Windows is pretty decent and gives you a very complete POSIX environment on Windows.
Re:What did we expect? (Score:4, Informative)
I use Windows for compatibility, but open-source for everything else: VLC, WinAmp, OpenOffice, Utorrent, et cetera.
I don't think you understand what open source is. Winamp and uTorrent are not open source.
Re:Really? (Score:5, Informative)
Interesting. According the article [linux.com] referenced in the Wikipedia [wikipedia.org] even OpenOffice and KOffice don't get along.
Re:What did we expect? (Score:5, Informative)
Re:What did we expect? (Score:3, Informative)
Not only that, but according to the article the formula's of ODF are in fact based on those of Excel in the first place. One might reasonably expect Microsoft to have some idea of how to interpret those...
Re:Really? (Score:3, Informative)
Re:They also claim Windows supports Posix (Score:3, Informative)
Last time I was checking, Windows' POSIX doesn't support fork(). Nor does it have to - for declared level of compatibility. (Whatever it is - lazy to check it.)
They also e.g. do not support signals. POSIX doesn't mandate support for all sets of features. All it requires that compatible programs can check - during compile time - which feature sets are supported, which are not.
Windows' POSIX is very similar to some heavily strip-down, *nix based embedded OSs. Few of them support fork() or threads, some support signals/RT extensions. Yet, they are POSIX compliant.
Re:What did we expect? (Score:5, Informative)
From the article:
The irony here is that the formula language used by OpenOffice (and by other vendors) is based on that used by Excel, which itself was not fully documented when OpenOffice implemented it. So an argument, by Microsoft, not to support that language because it is not documented is rather hypocritical. Excel supports 1-2-3 files and formulas and legacy Excel versions (back to Excel 4.0) neither of which have standardized formula languages. Why are these supported? Also, the fact that the Microsoft/CleverAge add-in correctly reads and writes the legacy ODF formula syntax shows not only that it can be done, but that Microsoft already has the code to do it. The inexplicably thing is why that code never made it into Excel 2007 SP2.
Re:Bullshit (Score:3, Informative)
Re:What did we expect? (Score:5, Informative)
"...1 second or so that it took to open the "Save file as" dialog..."
It takes 2 seconds for a menu to appear on my work XP laptop when I click the Start button. It takes forever to open a Word document. Virus scanning is now part of the Office experience and can't be disregarded. And this is on a more modern computer. What is your point.
Re:Agreed ... interoperability harms Microsoft (Score:5, Informative)
Åpne dokumentstandarder blir obligatoriske i staten. [regjeringen.no]
My rough translation from Norwegian:
- Norway has so far lacked a policy regarding the area of software. This have now changed. This Cabinet has decided that IT-development in the public sector shall be based upon Open Standards. In the future we will not accept that State activities locks users of public information to Locked Formats. - Heidi Grande Røys [wikipedia.org] (Minister of Government Administration and Reform).
Microsoft might play their games to hinder development as much as they can, but at least in this country the turn towards Open Standards seems inevitable.
Re:What did we expect? (Score:3, Informative)
I just skimmed through the ODF 1.1 specs and couldn't find anything about specifying formulas, besides the XML attributes that should be used. Nothing about the formula syntax. Can you be more specific what "general syntax" means and give a pointer to a page in the specs to support your claim?
The specs don't tell me how I should implement a formula. I need to look at OpenOffice.org to make my hypothetical ODF 1.1 compliant application interoperable. The problem is that Microsoft don't care about interoperability, they simply want to support the standard. They have absolutely no incentive to make things any better than they're currently in the specifications.
The standard should be written in such way that you have to "play nice" to be compliant. If it is not, someone known to avoid interoperability will continue to do so, until forced by the standard.
Of course, you can never create perfects specs that can't be purposefully misinterpretted in ways that break everything they intended, but at least if the specs are good enough the malice will be obvious to everyone.
Now even if ODF 1.2 comes out of the draft stage, Microsoft will probably continue to support the "broken" ODF 1.1 as long as possible.
What we have currently failed to force Microsoft adopt anything aimed at interoperability. That's a bad thing, but at least all other office applications are slowly adopting ODF in the place of the gazillion formats we had -- .wpd, .sxw, .kwd, .abw and what not. At least this mess is going away and there is a standard format for everyone (but Microsoft). And even with the incomplete specs, everyone else seems to be getting it right. That speaks for itself.
Excel, not Word (Score:4, Informative)
Re:What did we expect? (Score:3, Informative)
Wanna keep making money? Put Linux on all your computers and migrate the currently installed Windows XP into virtual machines. You've not instantly moved into the 21st century with a far more secure and stable platform to build on and have backwards compatibility.
This pretty much what Microsoft is saying you should do with Windows 7/Vista SP3 except they seem to think the bloated mess called Vista is a solid base. In reality, it's not a solid base, it's a new treadmill and has the same old billing meter tied to it and feeding your profits back to One Microsoft Way.
Get the facts straight. IMO.
LoB
Re:The problem is formulas. (Score:4, Informative)
Because it's bloody hard to do.
Microsoft's spreadsheet formula language in OOXML is actually a copy-and-paste job from the Excel help files. It doesn't provide nearly enough information to re-implement. It was only added as an afterthought, when Microsoft started complaining that ODF didn't have a spec for spreadsheet formulas, made a big deal about it, and then realised that OOXML didn't either.
ODF does have a formula language specification. It specifies something like 400 functions in precise detail, loosely based on what OOo, Gnumeric, and others (including Excel) already do. This has been a work-in-progress since 2005 (before Microsoft started complaining about ODF), and is basically finished (for now). It's to be included in OpenDocument 1.2 (the next version), but most other OpenDocument-capable spreadsheet apps already use these formula specifications on OpenDocument 1.1 documents.
Microsoft just chose to ignore it, and roll their own. As usual.
Re:What did we expect? (Score:5, Informative)
Actually there was a time when Microsoft was hailed as the white knight in the shiny armor freeing us from the evil IBM empire.
I've heard this said, but somehow I managed to miss it. I started work in the industry in 87, and had first encountered microsoft probably in 84. Outside of ziff-davis style vanity press, everything about MS was about what crap they were technically and ethically. The white knights were DEC, BSD, Borland, Commodore, ...
It was pretty obvious to many techies by the early 90s that Microsoft software was crap. The printed press was one of its tools and perpetuated the myth that companies would be better off with Microsoft. By 1995 it was getting out to a more general crowd how bad Microsoft was but these people still required having their eyes and minds open. Considering where they are today, it's obvious many are still pretty ignorant to their business practices and technology in general. By 1995, even the author, Douglas Adams saw this:
Microsofthttp://www.gksoft.com/a/fun/dna-on-microsoft.html
Here's a quote from the end of that short article:
"The idea that Bill Gates has appeared like a knight in shining armour to lead all his customers out of a mire of technological chaos neatly ignores the fact that it was he who by peddling second-hand, second-rate technology, led them all into it in the first place."
Over $200 million in marketing spent on Window 95 and about the same amount the following year pushing NT as _the_ server OS suckered in enough to seal their position in the market. That seal is leaking now but unfortunately, the general population of computer users and IT execs are mostly just as naive as they were in the early 1990s. It's the OEM's who are driving the market now because of very low margins and the high relative cost of Microsoft software.
LoB
Re:What did we expect? (Score:3, Informative)
Re:Really? (Score:3, Informative)
It's more like embedded assembly language. You transport the C code to a different chipset or OS, and maybe it doesn't work any more... the hardware and system calls are different. The formulas are "system calls", in effect: They reference code that's part of the spreadsheet application; it isn't embedded in the spreadsheet document.
Problem is, formulas are an integral part of spreadsheets and thus they need to be portable from application to application if the document format is supposedly going to be supported by both. There needs to be some standard to achieve this.
No, that's not it. (Score:4, Informative)
The problem isn't that you can't open a Word 2007 ODF document in another ODF compliant program, it's that it refuses to open to other program's ODF documents.
If you actually read the article, you'll find that Google, KSpread, Symphony, OpenOffice, and the Sun plugin are all unable to open documents created in Excel 2007. The issue here is not that it's one way, it's that the MS interpretation is different from what everyone else uses (though the actual specification leaves it open). And it's also about spreadsheets (Excel), not word-processor documents (Word).
The Microsoft formulas aren't actually conformant (Score:5, Informative)
Microsoft's supposed ODF 1.1 spreadsheet output is not compliant with the ODF 1.1 specification.
From 8.1.3 (emphasis mine):
From 8.3.1 Referencing Table Cells (emphasis mine):
Now look at a Microsoft formula in their ODF 1.1 spreadsheets. You'll see a formula attribute value of "msoxl:=B4-B3". For that to be correct per the ODF 1.1 specification, that should be "msoxl:=[.B4]-[.B3]". Compare this to the OpenOffice.org and OpenFormula syntax:
msoxl:=[.B4]-[.B3]
oooc:=[.B4]-[.B3]
of:=[.B4]-[.B3]
Ignoring the prefix, they're identical. Furthermore, the formula functions used by OpenOffice.org are generally based on the functions in Excel to begin with (such as "TODAY", for example), so I can only conclude that Microsoft is intentionally sabotaging interoperability to keep people from using ODF while still claiming conformance.
Re:Hypocrisy (Score:2, Informative)
Re:They also claim Windows supports Posix (Score:3, Informative)
True.
But to the point. If Windows supports fork(), please show to me its MSDN help page. All crap Windows supports - or supported in past - is on MSDN. But not fork(). I searched - found none.
Re:This is a REQUIREMENT so that Excel can be read (Score:5, Informative)
On the contrary, it does make sense to alter them because there is something wrong with Microsoft's formulas. For example, consider the MAX() function in Excel:
Now consider the OO.o (and forthcoming ODF 1.2 standard) equivalent:
OO.o uses semicolons instead of commas to separate parameters; so what? Well, let's what would happen if you were European, and tried to do the same thing in Excel:
Uh-oh! Now, since Europeans use commas instead of periods to indicate decimals, Excel suddenly thinks that there are 8 integer parameters instead of 4 decimal ones! Excel is wrong! In contrast, here's how it looks in OO.o:
Hey, whaddya know: still four decimal numbers! It works!
But that's just the tip of the iceberg. If you read previous posts in the linked blog, the guy points out how (for example) most of Excel's date and financial functions are wrong (not just because of syntax, but because they implement the wrong algorithms).
Actually, it does -- 300-odd pages worth of one, in fact. But Excel doesn't follow that either!
In fact, those date and financial functions tend to give answers different from both the OOXML standard and the original financial standards they are supposed to be based on!
Re:This is a REQUIREMENT so that Excel can be read (Score:3, Informative)
Excel uses semicolons to separate arguments when the decimal punctuator is the comma in the Windows regional settings.
MAX(2,5,6,4,2,1,5,8)
gives an error.
Oh, and if you open an Excel spreadsheet containing that formula on a PC with European regional settings, the commas are automatically changed to semicolons.
Re:What did we expect? (Score:3, Informative)
Instead of asserting the alleged inconsistencies in my response, why don't you state what you are trying to prove because I somehow fail to see any coherent message
I'm stating that you can still see dll hell in various programs and that .NET does nothing to solve this issue because the programs that you see them with are written in C/C++ not a .NET language. Was that simple enough for you?
Comment removed (Score:3, Informative)