GNOME and OOXML [LWN.net]

By Jonathan Corbet
October 30, 2007

The OOXML document standard being pushed by Microsoft has caused a certain amount of stress within both the development and commercial sides of the free software community. In some quarters it is seen as the latest attempt by a monopolistic firm to co-opt free software and the move to more free file formats; they would like to limit our involvement to opposition to the adoption of OOXML as a standard. Others see it as an attempt by Microsoft to come to terms with the demand for more open formats and to promote, in its own special way, interoperability. Few people really think we need this particular format, but many feel that, given that it will exist, it might as well be documented and, to the extent possible, its development should be encouraged to go in relatively useful directions.

This debate returned to the foreground recently with the publication of this open letter to the GNOME Foundation on a site named, for better or worse, "Fanatic Attack." This letter begins:

It appears that the Gnome Foundation is participating in ECMA TC 45 regarding resolving comments and contradictions for DIS 29500. Given the technical shortcomings in the specification and the disregard for process that the backers of DIS 29500 have displayed during the process, Gnome's participation in this activity is to the detriment of interoperability among office suits [sic].

The letter is long and strongly-worded, but it is rather short on information about just what the GNOME Foundation's participation in this process actually is. It turns out that the letter's author never asked that question, but LWN did. One answer can be found in this response posted by GNOME Foundation board member Jeff Waugh:

While Jody Goldberg (Gnumeric maintainer) was at Novell, he had been doing rocking work on TC45-M to make sure OOXML didn't just slip through, under-specified and uninvestigated. When Jody left Novell, the GNOME Foundation joined TC45-M to support his participation, so he could continue to "keep the bastards honest". OOXML is better documented as a result of his participation.

Participation in ECMA and implementation of OOXML do not indicate support for it as an ISO standard. There are plenty of other organisations with similar "political expectations" as GNOME involved in TC45-M, most likely for many of the same reasons.

There is also an explanation from Jody Goldberg posted on the Foundation's mailing list:

OOX is a file format that is in use, and we will have to interact with it. The opportunity to improve the spec and have MS answer questions and clarify necessary details should not be wasted.

It's worth noting that Mr. Goldberg does support the standardization of the OOXML format.

This episode has inspired a certain amount of complaint on the Foundation mailing list. The problem is not the participation in the committee, which appears to be relatively uncontroversial there, but the fact that this particular controversy was not anticipated and addressed ahead of time. Had the Foundation issued a press release at the outset explaining what it was doing, it would not have to be engaging in a damage control effort now. As it is, said press release appears to be under construction, but it will likely be less effective than it could have been.

In any case, this response will not satisfy everybody. There appears to be a fundamental difference of opinion in the community over how we should deal with the OOXML effort. While nobody seems to really like this standard (OK, almost nobody), not everybody dislikes it in the same way. To some, OOXML is characterized by patent problems, extreme complexity, opaque binary blobs, and the questionable tactics of its corporate backer. For those people, any engagement with the standardization process other than outright opposition is an unacceptable compromise. They see no good that can come from recognizing this standard in any way when we already have a standardized open document format which needs support.

On the other hand, the truth of the matter is that this format exists and is in use. Free software will end up supporting this format, not (just) because certain companies want to sell services into corporate environments, but because interoperability has always been a high priority in our community. If, some day, we as a community decree that we are strong enough that we do not need to support formats we don't like, we will have lost something important.

One should not overlook another important component in this situation: the fact that OpenDocument is not the final answer to document formats. Instead, it seems that the level of criticism of this format is growing, and that development of document formats will have to continue into the future. We do not, in other words, have all the answers in this area.

So, assuming that we, as a community, do intend to interoperate with the OOXML format, it makes sense to take advantage of the opportunities presented by the standardization process to ensure that the format is (1) not completely irrational, and (2) documented as completely as it can be. Participation in the process at this level has the potential to save a lot of work and interoperability hassles in the coming years.

Once upon a time, the free software community would have had no influence over a major manufacturer's file formats. We have succeeded in changing the world to the point where such formats are expected to be open, and where our comments on those formats have to be taken seriously. To refuse to wield that influence would, in essence, be a decision to go back to the days of the early 1990's, when our thoughts were mostly confined to a few small mailing lists and went generally unheard. That would not be a step forward for our community.

That said, participation in groups like standards bodies should be done the way we do almost everything else: in full openness. The GNOME Foundation exists to represent the community of GNOME developers, many of whom, it seems, were unaware that the Foundation was representing them in this particular forum. What form this representation has taken, and what has been accomplished by it, is still somewhat unclear; this lack of transparency has made the recent flames possible. The GNOME Foundation board, presumably, knows what positions are being taken by its representative on the ECMA committee; it would behoove that board to be more active in communicating that information to the Foundation's members.

to post comments

False dichotomy

Posted Oct 30, 2007 17:24 UTC (Tue) by stevenj (guest, #421) [Link] (11 responses)

Is it just me, or is there a false dichotomy floating around here? There is no fundamental contradiction between wanting to interoperate and pressing Microsoft to publish and improve documentation for whatever formats are in their latest products, and at the same time opposing the idea that this redundant mishmash of in-house formats should be blessed as an official ISO standard.

Yes, press MS to clarify as much as possible. Yes interoperate as much as possible in order to provide a viable FLOSS escape route from MS Office. And then turn around and vote no on the ISO standard: there is no benefit to users or industry in having a second office-productivity format (not to mention one with two of its own incompatible vector-graphics formats, a new equation format, and other disregard for existing standards [the Gregorian calendar, anyone?]).

If you think that annointing whatever MS deigns to document as an ISO standard is the only way to get them to document their formats, no matter how redundant or incomplete or badly engineered it may be, then the price is too high—we are better off reverse-engineering, as was done with the binary format. (And will have to be done anyway, most likely, as there is no indication that MS will limit themselves to following the ECMA/ISO version of their format.)

False dichotomy

Posted Oct 30, 2007 17:56 UTC (Tue) by ajross (guest, #4563) [Link] (2 responses)

Agreed.  No one would bat an eye if GNOME announced a project to write a library that
abstracted the (reverse-engineered) binary .doc format for applications.  But try working with
the vendor on an *actual* standard (however flawed it might be) and they get flamed?  Sigh.

False dichotomy

Posted Oct 30, 2007 18:40 UTC (Tue) by sayler (guest, #3164) [Link]

http://www.itwire.com/content/view/15089/1091/1/1/

Speaking of trolls :P

Maybe I'm just a corporate shill, but working on *two* fronts, as opposed to just one seems
like a good idea to me.

False dichotomy

Posted Oct 30, 2007 22:10 UTC (Tue) by stevenj (guest, #421) [Link]

Actually, I was thinking of the other side. People who are opposed to ISO standardization are accused of not caring about interoperating with MS Office or of not wanting documentation for MS formats. And some GNOME personalities (*cough* Miguel) seem to think that helping ISO bless OOXML is the only way to get documentation out of MS (and is worth the cost of having two incompatible ISO standards).

False dichotomy

Posted Oct 30, 2007 19:00 UTC (Tue) by nim-nim (subscriber, #34454) [Link] (7 responses)

Unfortunately, OOXML standardization is not a technical process but a battle of influence
right now and Microsoft is spinning every FLOSS actor contribution to the ECMA process to
"prove" to good-willing but FLOSS-ignorant national standard bodies there is strong support
for ISO OOXML standardization FLOSS-side.

That includes spinning quotes from personalities very aware of this political game and eager
to help (Miguel), and spinning quotes from people like Jody Goldberg that claim they want to
ignore the political aspects of OOXML/ODF ands thus plays right into Microsoft hands
(Microsoft just needs to get its numerous parters repeat and amplify the positive things
written about OOXML and ignore the others, and no one's the wiser).

Also:

1. Some people have no clue how ISO standardization will be used by vendors and feel that if
the price to get Microsoft format documentation is to get it rubber-stamped at ISO that's
something acceptable.

2. For someone involved in an application that needs to parse Microsoft formats there is this
strong temptation to play along with Microsoft to get access to good documentation on its
formats, while turning a blind eye to how Microsoft uses this involvement to lend credibility
to its ISO target.

3. It's very difficult for a FLOSS hacker (even if this hacker worked for an editor like
Novell) if he has not spend some time in a big corporation to understand how Microsoft is
positioning OOXML. Microsoft is not asking to standardize a word processor or spreadsheat
format. It's asking to standardize data containers that can talk to server apps, be consumed
and generated by them (and yes the MS formats are woefully inadequate for the task but no that
hasn't stopped people from doing it with .doc and .xls and now MS is asking ISO to bless OOXML
for this). That's written black on white in the OOXML spec preamble.

That's something Gnumeric never participated in. That's something Jody is woefully unprepared
to evaluate. ODF is genuinely better than OOXML for this use case, and when Jody complains of
ODF XML-isms it just shows he has not the slightest idea of what SUN, IBM & Microsoft are
battling for.

The money is not in the office suite. It's getting commodized. The money is in the expensive
corporate server apps, and how the client can be used to force (Microsoft) or preserve (Sun,
IBM) particular software stacks on the servers. Needless to say there is little room for FLOSS
or Linux servers if they need to talk to rich office clients in OOXML-lingua, process
Microsoft-dates, parse EMF schemas, etc. That's internet round 2: Microsoft missed the HTML
boat, let Apache establish itself, now it wants Office not the browser to provide access to
enterprise infrastructure, and root as many non-MS stuff server-side as possible in the
process. Adding office components to the browser as activex was a failure. Now the game is
adding browser/MUA aspects to office suites (and let them drown the W3C open bits). IBM plays
the same game with its Notes+OpenOffice.org welding.

And no one cares what non-enterprise users get as office suite or network client, as they
don't pay any licenses anyway.

Unfortunately entities like the GNOME Fundation seem not to have the slightest clue what the
game is and what the costs of letting individuals create the impression of its support to
OOXML will be. Delegating desktop people like Jody to evaluate OOXML when the prize is
server-side, shows a profound lack of market understanding.

False dichotomy

Posted Oct 30, 2007 22:26 UTC (Tue) by man_ls (guest, #15091) [Link] (6 responses)

The money is not in the office suite. It's getting commodized [sic]. The money is in the expensive corporate server apps [...].

I have to disagree. The money is in a lot of places, including the office suite, the corporate apps and whatever you can sell for a profit. This kind of reasoning is indeed a false dichotomy: you don't have to choose between suite and server applications, or corporate vs home user. And Microsoft goes for all of them at once. That is their true virtue.

False dichotomy

Posted Oct 31, 2007 0:48 UTC (Wed) by drag (guest, #31333) [Link] (1 responses)

The money is all over the place, definately. 

I'd have to agree with both of you guys. Very smart stuff.


Now the fundamental problem is.. OOXML is going to win. More then likely. Everybody already
uses Microsoft Desktop, Microsoft Server, and Microsoft Office.  Even if, through a work of
nature, all of the standardization folks just stand up and turn their backs completely on
Microsoft and OOXML then it's still going to be much cheaper and easier for 80-90% of the
market to just keep on using the same software they are using right now.

Trying to stop OOXML is going to be something like standing in front of a 500 pound wrecking
ball hurtling towards a building. Your probably not going to have much luck stopping it.
However if you time it right you might have a pretty good chance of steering it.. 


Is this  container format anything like media container formats? Like with Quicktime or Ogg
you can have all sorts of different types ecodings inside them; Mpeg4 variations, Vorbis,
Flac, Speex, AAC, etc etc

I don't understand all of this, but if it's like media stuff... if you have all sorts of
software on the server side to handle OOXML then would it be easier to just swap out the
internal format for a more favorable one rather then try to replace OOXML entirely? (assuming
that OOXML gets widely established)

False dichotomy

Posted Nov 2, 2007 13:35 UTC (Fri) by vonbrand (guest, #4458) [Link]

Now the fundamental problem is.. OOXML is going to win. More then likely. Everybody already uses Microsoft Desktop, Microsoft Server, and Microsoft Office. Even if, through a work of nature, all of the standardization folks just stand up and turn their backs completely on Microsoft and OOXML then it's still going to be much cheaper and easier for 80-90% of the market to just keep on using the same software they are using right now.

But this isn't the same software, it is a whole new set of formats! Sure, MSFT has a grip over (and includes) the legacy formats in OOXML, but this is more a battle for establishing the new format from both sides.

False dichotomy

Posted Oct 31, 2007 20:31 UTC (Wed) by nim-nim (subscriber, #34454) [Link] (3 responses)

> I have to disagree. The money is in a lot of places, including the office
> suite, the corporate apps and whatever you can sell for a profit.

However you can't sell for profit Office suites as tools to create standalone documents
anymore (at least not to informed users, as corporate purchasers are). Their market value has
not reached that of the browser yet, but it's getting close fast (thanks in part to
OpenOffice.org)

Nowadays Office workers do not complain their office-document-producers are not good enough,
they complain they're drowning in mail and web apps and can please someone integrate all this
so they don't have to retype the same info all over the place or open scores of web pages to
work. They don't create office documents from scratch on the desktop anymore, they format data
created or extracted on the server or sometimes just put the finishing touches to documents
partially pre-generated on the server.

Remember:

When the internet exploded, Microsoft tried very hard to neuter it. Pushed exchange and
created a Notes/Outlook duopoly (very successful in getting IMAP nowhere). Used IE to kill
Netscape, and then stopped investing in IE to freeze the browser at a safe level. "Sabotaged"
SUN applet plans. Bill's original vision was a PC for everyone, with the processing done on
the PC, and an end to specialized computers or big centralized mainframes. Crippling the web
client would keep added value desktop-side, where Microsoft was well positioned to harvest it.

Yet as soon as it become clear the desktop was Microsoft-owned, other editors stopped bringing
new innovative applications there, and focused on the server-side (where you could introduce
new lucrative enterprise apps without an inconvenient partner eating all your profits).
Despite the crippling of the network interface, J2EE thrived. Added value and corporate
budgets started leaving the desktop. History showed the browser was not crippled enough, and
with Firefox ready to replace IE Microsoft can not put this particular genie in the bottle.

So Microsoft had to abandon its historical vision to continue growing. Forget PCs for
everyone, welcome to the "computing cloud". Computer cloud being the same things everyone else
is doing, except not in SUN/IBM/BEA/Oracle/Apache/SAP J2EE over *nix, but in .C# over windows,
not using W3C standard formats, but Office XML customized lingua, not accessed through the
browser, but through a network-enabled Office.

The money in this kind of configuration is:
1. server-side
2. in the tools users need to access server-side processing

The nice thing for Microsoft is that even if a dumb IE didn't stop server-side processing
growth, a large IE userbase is very effective in hampering Google+Mozilla+W3C efforts to make
the browser a satisfying server application entry point. IBM realized it too, but it will take
some time before in manages to make OpenOffice.org + Notes + Java + Eclipse lean enough to be
a no-brainer alternative.

On the other hand Microsoft Office already has all the nice data presentation, data input and
data persistence capabilities needed, and has its own bloat hidden by vertue of being
massively pre-loaded in memory.

So while competitors are stuck, adding server application entry point capabilities to Office:
1. de-commodizes Office as a product (get this OpenOffice.org)
2. adds a nice coupling between Windows-as-a-desktop and Windows-as-a-client (get this J2EE +
*nix)
3. opens the possibility to get part of Microsoft networking conventions officially
standards-blessed, by including them in the "Office" format sent to ISO (get this
W3C+Mozilla+Google)

If you take a look at what the French NB asked to remove from OOXML, you'll see everything not
legacy-related is there to help MS Office talk to MS server apps. And that Microsoft is
fighting tooth and nail to keep this stuff not traditionnaly associated with Office suites in
the same standard (otherwise customers my take one but not the other)

False dichotomy

Posted Oct 31, 2007 22:19 UTC (Wed) by man_ls (guest, #15091) [Link] (2 responses)

However you can't sell for profit Office suites as tools to create standalone documents anymore (at least not to informed users, as corporate purchasers are).

What? You tell that to Microsoft's Office division, which beat records (20% up) again this year.

Seriously, you can play the strategist and think that the future lies elsewhere. But Microsoft's profits are firmly entrenched in the present, which is operating systems and office suites. While they use existing monopolies as footholds to enter other markets, it is hard to catch them off-guard in their home turf.

Their market value has not reached that of the browser yet, but it's getting close fast (thanks in part to OpenOffice.org)

You make it look as if browsers costed huge quantities of money in the past, and then lost their value. That is not true. Browsers never cost anything since the early days of the internet (Mosaic, then Netscape, then IE, then Mozilla; only Netscape attempted to extort corporate users, and failed miserably). No, browsers were "commoditized" from the beginning.

Yet as soon as it become clear the desktop was Microsoft-owned, other editors stopped bringing new innovative applications there, and focused on the server-side (where you could introduce new lucrative enterprise apps without an inconvenient partner eating all your profits).

This is too simplistic. Other players (Adobe, Quicken) are making lots of money on the desktop.

So while competitors are stuck, adding server application entry point capabilities to Office: 1. de-commodizes Office as a product (get this OpenOffice.org)

That is interesting and may be true, but the basic reasons still rule IMHO: Microsoft wants to make OOXML an ISO standard basically not to lose existing customers, which may want to switch to something not so blatantly proprietary.

As to server integration, Microsoft has tried this kind of thing in the past and failed miserably. For one thing their web server sucks big time; for another (not unrelated) aspect, security is a huge deal in server infrastructure and Microsoft's record there is quite poor. But they are also famous for trying many times before getting things right, so maybe this time they will succeed. Let's hope not.

False dichotomy

Posted Oct 31, 2007 22:52 UTC (Wed) by nim-nim (subscriber, #34454) [Link]

>> However you can't sell for profit Office suites as tools to create
>> standalone documents anymore (at least not to informed users, as corporate
>> purchasers are). 
> What? You tell that to Microsoft's Office division, which beat records
> (20% up) again this year.

Because the Office division is not selling tools focused on creating standalone documents
anymore. They sell VBA automation. They sell desktop-to-server solutions. Strip this and you
won't find a lot of entities ready to pay the price Microsoft asks just for the capability to
create .doc and .xls documents (with no macros, no data feeds in and no data feeds out)

> This is too simplistic. Other players (Adobe, Quicken) are making lots of
> money on the desktop.

And they got there when? Before Microsoft consolidated its desktop hold. Had they started
later they wouldn't have targeted the desktop. Sure there are interesting things to do
server-side, but that's not the reason why no one is trying to do new desktop apps anymore.

> But they are also famous for trying many times before getting things
> right, so maybe this time they will succeed.

Going XML and modern programming language is helping them a lot. Sun and IBM would not be so
agitated otherwise. Their pure Office suite revenue is minimal

False dichotomy

Posted Nov 1, 2007 20:29 UTC (Thu) by Los__D (guest, #15263) [Link]

MS is very much succeeding in this strategy (It's almost impossible to sell any kind of business software without being met with a demand for SharePoint integration), and they'll definately mainly use Office as a way to create a new lock-in.
We're lucky that our software is so unique that companies accept it as a standalone product (If we didn't offer AD integration though, we'd be game over), but I'm pretty sure that I'll be asked by my boss to port our software to their crap soon... *sigh*

GNOME and OOXML

Posted Oct 30, 2007 19:27 UTC (Tue) by halla (subscriber, #14185) [Link] (3 responses)

"One should not overlook another important component in this situation: 
the fact that OpenDocument is not the final answer to document formats. 
Instead, it seems that the level of criticism of this format is growing, 
and that development of document formats will have to continue into the 
future. We do not, in other words, have all the answers in this area."

I've heard this said three times in three different places today already. 
And it rings false; it sounds fair and objective, but is little more than 
meme-repeating. It also claims something about ODF that is not true: 
namely that it is positioned as the definitive, finished document format 
that will remain the same unto the ages of ages.

In reality, ODF is evolving, within the standards process, with input 
from everyone involved. Look at the way KOffice is genuinely innovating 
within the ODF file format. Of course, if, as in the news.com article 
quoted above, your definition of "meeting business needs" is 
interoperating with Microsoft, then ODF won't work for you. But that is 
not a fault of the standard: it is a conscious choice on Microsoft's 
part. And yes, HTML tables are different from wordprocessor tables. 

But in the end, splintering effort between ODF, CDF and OOXML is exactly 
what will mean having to suffer locked-down documents for the next 
decade. Trying to implement OOXML is simply impossible for anyone, even 
for Microsoft (since their own applications do not follow their own 
standard). Trying to implement ODF is feasible for us.

KOffice and ODF

Posted Nov 1, 2007 3:05 UTC (Thu) by bignose (subscriber, #40) [Link] (2 responses)

> Look at the way KOffice is genuinely innovating within the ODF file format.

I'd like to. Care to provide some links so we can actually see this innovation of which you
speak?

KOffice and ODF

Posted Nov 1, 2007 4:44 UTC (Thu) by sbishop (guest, #33061) [Link]

Here's one:

http://dot.kde.org/1188249220/

Look for the paragraph talking about Marijn Kruisselbrink's work.  It has to do with embedding
musical notation inside ODF documents.  I don't know much more about it, but I believe that's
what boudewijn was referring to.

KOffice and ODF

Posted Nov 1, 2007 7:53 UTC (Thu) by halla (subscriber, #14185) [Link]

ODF originated within the model of coarse-grained document composition: embedding documents
within documents. KOffice2 is using ODF to store documents composed of fine-grained objects.
We're bridging the dichotomy between the creative worker and the office worker by having the
full range of  applications and components available. And we're adding object types that have
never before been available to anyone, such as editable musical notation. And color management
across the board. And, but that's only started just now, workflow management using the
integrated project planner.

And as for links:

http://wiki.koffice.org/index.php?title=Architecture
http://dot.kde.org/1168284615/
http://akademy.kde.org/conference/talks/06.php

and of course, most importantly:

http://websvn.kde.org/trunk/koffice

More bad news for ODF

Posted Oct 30, 2007 19:57 UTC (Tue) by leoc (guest, #39773) [Link] (1 responses)

http://www.news.com/8301-10784_3-9806369-7.html

this is a tiny fringe viewpoint being taken as something else

Posted Oct 30, 2007 22:05 UTC (Tue) by stevenj (guest, #421) [Link]

See Rob Weir's blog for a different side of this story. Gary Edwards is does not really represent the many people with an interest in ODF; his "foundation" seems mainly to consist of two people, and it's unfortunate that they are making themselves into a tool of the very OOXML advocates they oppose.

GNOME and OOXML

Posted Oct 30, 2007 20:41 UTC (Tue) by tialaramex (subscriber, #21167) [Link] (4 responses)

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.

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] (1 responses)

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.

GNOME and OOXML

Posted Oct 30, 2007 21:33 UTC (Tue) by jdub (subscriber, #27) [Link] (2 responses)

Firstly, thanks for a balanced (and informed!) article. LWN rocks. :-)

The conclusion is a bit rough -- our participation was very much a matter of public knowledge,
as it was mentioned in the Board meeting minutes *and* discussed on foundation-list at the
time.

The issue Luis raised was that we didn't do some kind of broader PR announcement at the time,
so that folks *outside* our community could understand the context of our participation.
Guilty as charged (though, as noted on the mailing list, it's unlikely that this would have
had any impact on the ill-informed "open letter").

GNOME Foundation members (who bother to read our minutes and the Foundation mailing list) were
all very much aware that we were participating, so there was no transparency issue for the
Foundation itself.

- Jeff Waugh, GNOME Foundation

GNOME and OOXML

Posted Oct 30, 2007 22:46 UTC (Tue) by louie (guest, #3285) [Link]

GNOME Foundation members (who bother to read our minutes and the Foundation mailing list) were all very much aware that we were participating, so there was no transparency issue for the Foundation itself.

Agreed completely. (Luis)

GNOME and OOXML

Posted Nov 3, 2007 12:53 UTC (Sat) by nim-nim (subscriber, #34454) [Link]

It's a pity the GNOME Foundation still has not managed to communicate a readable position on
the new office formats, when KDE is cristal-clear on the subject:

http://dot.kde.org/1194021253/

All the "we participate in ECMA except we don't really support OOXML as an ISO format which is
what ECMA is working on and the slides published by our representant write OOXML should be
ISO-approved as do the quotes Microsoft spreads or what our Novell members say at every
opportunity and why are you flaming us anyway we understand ourselves" is not terribly
convincing.

The issue is big enough closing ranks to avoid contradicting old friends (that's how it feels
from the outside) may not be the best policy.

GNOME and OOXML

Posted Oct 31, 2007 0:30 UTC (Wed) by drag (guest, #31333) [Link] (1 responses)

*shrug*

All I know is that Microsoft rules the desktop and rules the office suite markets. What they
choose is what is going to get used the vast majority of people.

That's the reality and that is the power that Microsoft has gotten for winning the 'lock-down'
on those markets. (no matter how dishonestly) There is no if's and's or but's about it.

Gnome and OpenOffice.org, one way or another, is going to have to be compatable with OOXML.
The choice is to do that, or to loose whatever relevence they've gained in the market place
over the past few years.

Sure, sure I'd prefer ODF for everything, but there is a lot of other things in the world I'd
like also that isn't going to be changed anytime soon. (at least not in the next 2 year
timeline)

If Migal or Novell or whoever, buy working with Microsoft can make OOXML work on the Linux
desktop then they are doing all of us a big favor, no matter how distastefull it is.

And if they are able to pull it off... then OOXML may work out as a standard after all and
everybody here gets exactly what they want; which is cross-platform document handling.

If they can't pull it off, even after all the hard work, honest effort, strife and the patent
bullshit... then that will prove to the world just how worthless OOXML is and Microsoft
shouldn't be listenned to when trying to establish standards.

I mean it's one thing to stand there and talk about how shittastic OOXML is and how ODF should
be used.... But it's another thing to PROVE that OOXML is shitastic by implimenting the
'standard' correctly according to the documentation and still failing miserably.

Either way it's probably going to end up being a win for the Open Source desktop as long as
they (the Gnome folk) are working hard and are taking a honest and open approach.

OOXML rigged

Posted Nov 1, 2007 13:26 UTC (Thu) by dwheeler (guest, #1216) [Link]

You're missing the point.  OOXML is carefully designed to NOT be fully implementable by anyone
other than Microsoft.  Stuff like an attribute meaning "do it the way Word6.0 does it" without
specifying what it does.  Besides, Microsoft has NOT committed to actually USING OOXML; I
fully expect that files written out by Office will _not_ stick to just the capabilities noted
in the OOXML specification.  No doubt, OOXML will be used, and applications will need to
ATTEMPT to work with it.   As a stepping-stone to a nonproprietary format, OOXML can work, but
it's not (and is not intended to be) a non-proprietary format that anyone can use or
implement.

GNOME and OOXML

Posted Nov 1, 2007 20:02 UTC (Thu) by rossendryv (guest, #34947) [Link]

Some basic facts about what the ECMA TC45 is proceeding with at this time so readers can
better understand the consiqueses of GNOME injecting themselves into this process. And putting
a stamp on this MS lead industrial cartel at ECMA with the Chairman and Co-Charmain MS
employees and all the other participant votes YES (besides IBM) for Fast Track approval and
sent to ISO. Please note it is in the interest of all the parties at ECMA TC45 for OOXML to be
ISO. (IBM partipated in the innitial vote only to make their position known clearly) All the
partipants now (IBM not present) at the ECMA TC45 were in that innitial YES vote and are
helping resolove comments so that OOXML becomes and ISO.

Robert Wier of IBM on the ODF List
"The practical difficulty here is that of timing. While I have no
doubt that Jody was instrumental in getting additional technical
disclosures from Microsoft back in 2006, Ecma TC45 is not in that mode
of operation right now. The OOXML standard Ecma 376 has already been
approved by Ecma. It is now before JTC1 as DIS 29500 and the text is
essentially frozen since December 2006. The only changes that can be
made to it must be in response to specific JTC1 national body ballot
comments. Jody can no longer go to a TC45 meeting and say, "Gee, I'd
like more information added on X, Y and Z". JTC1 rules forbid changes
to the standard that are not traceable to a national body comment.

Certainly, Jody or any other Ecma TC45 member so inclined can help
Microsoft address the thousands of ISO comments that were received,
and help prep OOXML for approval by JTC1. There is certainly a lot of
grunt work to be done there. But let's not call that anything but
what it is -- helping Microsoft gain ISO approval.

From Richard Stallman on the Gnome list today:

"Is joining ECMA TC45 really like using a library? According to your
own words, it is engaged in modifying the OOXML spec:

That is inaccurate. Whom do you think will be responding to
national body issues ? ECMA, and by proxy TC45, have the ability to
propose changes in the spec to resolve issues, and to raise their
own issues preemptively for resolution.

I gather that such modification intended to bring about the acceptance
of OOXML as an ISO standard. (Please correct me if I'm wrong.)

If that is the case, anyone who is represented on the ECMA committee
is helping to promote the ISO acceptance of OOXML -- which would hurt
our community substantially. If the GNOME Foundation is to be
represented in on the ECMA committee, it should explicitly counteract
that backfire effect by doing something else.

One way to do so is by publishing a statement, addressed to all
countries that vote in ISO, asking them to vote against any and all
versions of OOXML as a standard"