GNOME and OOXML [LWN.net]

GNOME and OOXML

Posted Oct 30, 2007 20:41 UTC (Tue) by tialaramex (subscriber, #21167)
Parent article: GNOME and OOXML

Jody's involvement was unknown to me but by no means a surprise.

As far as spreadsheets are concerned, both the prospective offerings in this space are
hopeless. Each reflects the peculiar biases and assumptions of the application software for
which it was originally developed, OOXML inherits from Excel, while ODF inherits from
OpenOffice.org Calc.

The trouble is that the spreadsheet structures directly reflect the design of the software,
and that software is itself very poorly specified, having been endlessly adapted to the
requests of myriad users. The implication would be that to read & write ODF well, you must
re-implement OpenOffice.org and the same with OOXML and Excel. To try to sidestep this, the
specification writers have often simply avoided specifying anything at all. Implementations of
ODF's spreadsheet format, for example, aren't required to share any meaningful functions or
method of expressing formulae, and so can't really open each other's spreadsheets. In my
opinion many of ODF's early supporters did not understand that a spreadsheet is more than a
wordprocessor table with numbers filled into it.

So the result is that either these standards don't standardise anything (so you can receive an
ODF spreadsheet and have no idea whether you will be able to open it, since it depends so on
which program saved it) or they standardise so much that you're effectively agreeing an ISO
standard of running Microsoft Office, which is redundant when it is already the de facto
standard.

I do not expect any meaningful progress to be made on this, and I regard the whole process as
worthless for that reason. Maybe it makes more sense for word processor documents, but I doubt
it. Our only hope of actually achieving spreadsheet interoperability is to clone Excel, which
we can do with or without an ISO standard. Jody's work on Gnumeric has helped with this
tremendously.

(Log in to post comments)

GNOME and OOXML

Posted Oct 30, 2007 20:56 UTC (Tue) by nim-nim (subscriber, #34454) [Link]

That's true for the "speadsheet as a way to massage numbers" excel use-case

That's false for the "speadsheet as a way to automate business tasks and talk to backend apps"
use-case.

The money and what Microsoft cares about is 2. OOXML is about 2. Gnumeric is about 1.

Take a look on CSS and JavaScript

Posted Oct 31, 2007 0:57 UTC (Wed) by khim (subscriber, #9252) [Link]

CSS proposal was closely tied to IE 4.0 back then. W3C took the standard, refactored it, made it more clear and now we have quite hight degree of interoperation between major browsers. Except IE, that is - because W3C thrown away a lot of stuff which tied CSS to IE and Microsoft never wanted to implement independent standard in first place: they wanted to force their vision on everyone (and almost succeeded BTW). Sure, they took some changes from W3C proposal - but left another ones unimplemented for years (more then 10 years for CSS1!).

JavaScript, on the other hand, was standartized in ECMA as mix of Communicator's and IE's quirks. Result is differences in implementation, total lack of test suite and real compatibility between browsers. Total mess to this day.

It does not matter what the initial position is: if participants are working toward interoperability - you can reach it over time. If they are not really interested in this work (and looks like Microsoft is not interested) - then it does not matter how good the initial standard is.

So I think ODF has a chance: may be it'll require ten or fifteen years to reach good level of interoperability - so what ? C++ took 10 years to write the standard and 5 years to get to the point where you can write standard-compliant program and have reasonable hope that it'll actually compile and work when used with compiler A or B (especially if it's not MS Visual Studio - but even it has adequate level of standard conformance novadays)... OOXML does have such a chance: Microsoft just want the rubber-stamp, it does not even plan to stick to the standard in future versions of MS Office!

GNOME and OOXML

Posted Oct 31, 2007 4:55 UTC (Wed) by eru (subscriber, #2753) [Link]

Implementations of ODF's spreadsheet format, for example, aren't required to share any meaningful functions or method of expressing formulae, and so can't really open each other's spreadsheets.

That is a problem that is being worked on. http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office-formula . Of course too bad it wasn't in the initial version of the standard.

GNOME and OOXML

Posted Oct 31, 2007 14:34 UTC (Wed) by tialaramex (subscriber, #21167) [Link]

That link leads me to a site which agrees with my assessment that it's an attempt to
standardise what OpenOffice.org already does (an approach which I described as hopeless) and
has this to say about the schedule...

Some old messages reported that we would not complete until October 2007, but that is simply
not true.

Indeed, with only hours of October 2007 remaining as I write this I think it's safe to say
that they won't complete until some time after that, if at all. The mailing list archives just
stop, abruptly, in July with a considerable amount of unsettled business.

I'm willing to believe that there's a good faith attempt to do something useful here, but it's
too little and too late.

Let me provide some additional perspective lest people (who don't know me) should imagine I'm
a mere puppet of the Microsoft Corporation. There are a number of curious features of Excel
that make no particular sense to the modern user, yet stubbornly refuse to disappear from new
& improved versions. How did they come about? They're related to design mistakes in earlier
software, in some cases as early as 1-2-3. Excel had to maintain bug-for-bug compatibility
with some of these mistakes and now they can never practically be eliminated.

All the date-handling functionality in Excel is duplicated for two distinct systems of
measuring time. These correspond to a more or less inadvertent difference between the original
Macintosh Excel and the first Windows version. That difference is baked into every
date-handling spreadsheet and must be detected at import time, there is no way to "convert"
from one to the other without human guidance.