Georg Greve found your comments on his article, "Novell's
Danaergeschenk" on Open XML intriguing enough that he has written a response, "OpenXML wrap-up after D12K", and I thought the best way to let you know about it would be to reproduce it here, which, thanks to his choosing a Creative Commons license, I can freely do. I also thought it would be useful because he addresses the "now what?" question. Novell gives no sign of changing course, so what should the community's response be? I believe this quotation is a helpful starting off point:
"I once preached peaceful coexistence with Windows. You may
laugh at my expense -- I deserve it."
Jean-Louis Gassée, former CEO, BeOS
As you know, the now defunct BeOS was one of the nine examples used in the opening statement in the Iowa antitrust trial to illustrate Micorosoft's anticompetitive practices and how they affect the marketplace.
To my mind, the only answer that makes any sense is to insist that Microsoft support ODF, as it ought to do. It's an ISO standard. It works. There is support for it and demand for it. Pardon my simplicity, but why isn't Microsoft just supporting the ODF standard? Why should the world have to do things Microsoft's way, instead of Microsoft abiding by the standard everyone else was happy to agree on, a standard actually designed to make true interoperability achievable? I can't find anyone knowledgeable who thinks this Novell-Microsoft translator will work well. Steve Ballmer himself says it won't work 100 percent. So what exactly is the game?
An anonymous reader left this insightful comment earlier:
Recent discussion on ODF versus MS-OOXML has been based around the notion that these are two competing comparable formats. It is instructive however to look at what the actual objectives of the standards committees were.
ECMA TC45 - Office Open XML Formats
Programme of work:
To Produce a formal Standard for office productivity documents which is fully compatible with the Office Open XML Formats This includes:
Produce a standard which is fully compatible with the Office Open XML Formats, including full and comprehensive documentation of those formats in the style of an international standard, with particular attention given to enabling the implementation of the Office Open XML Formats by a wide set of tools and platforms in order to foster interoperability across office productivity applications and with line-of-business systems.
- Produce a comprehensive set of W3C XML Schemas for the Office Open XML Formats, with particular attention given to self documentation of the schemas and testing of the XSDs for validation using a wide variety of XSD tools of the market and cross platform.
- To contribute the Ecma Office Open XML Formats standards to ISO/IEC JTC 1 for approval and adoption by ISO and IEC.
Note the key phrase "produce a standard which is fully compatible with the Office Open XML Formats" In other words, the objectives of the ECMA comity for Microsoft OOXML was simply to document the file format as used in Microsoft's new version of MS-Office.
By comparison, the objectives for ODF were:
OASIS Open Document Format for Office Applications (OpenDocument) TC.
Statement of Purpose
The purpose of this TC is to create an open, XML-based file format specification for office applications.
The resulting file format must meet the following requirements:
- it must be suitable for office documents containing text, spreadsheets, charts, and graphical documents,
- it must be compatible with the W3C Extensible Markup Language (XML) v1.0 and W3C Namespaces in XML v1.0 specifications,
- it must retain high-level information suitable for editing the document,
- it must be friendly to transformations using XSLT or similar XML-based languages or tools,
- it should keep the document's content and layout information separate such that they can be processed independently of each other, and
- it should 'borrow' from similar, existing standards wherever possible and permitted.
In other words, the objective of ODF was to create an open format tied to no particular vendor's product, which is usable by everyone, and which is designed to work with other standards.
I think what this shows is that ODF and MS-OOXML are not intended to be equivalent to each other. MS-OOXML is the proprietary file format for a product Microsoft happens to be shipping today (or soon at least) and Microsoft is just doing what people have been asking them to do all along - documenting their file formats. ODF however is intended to be something much broader and more permanent than MS-OOXML. Another way of looking at it is that ODF is a document standard while MS-OOXML is a product brochure.
When people talk about ODF versus MS-OOXML, we should be clear that they are not comparable in their scope or in their objectives. Getting ECMA to rubber stamp someone's product literature doesn't make it a genuine industry standard. We should always clearly make a distinction between a genuine standard and a product specification and not let someone's marketing department obscure the difference between the two.
Make no mistake: the choice isn't between being able to interoperate with Microsoft, thanks to Novell doing interoperability work for them, or being stuck in some ODF ghetto, unable to read Microsoft documents. Everyone wants to interoperate. The question is how. The problem is Microsoft. The solution lies with Microsoft. They need to get with the program and follow standards like everyone else, instead of insisting the world bend to their ways.
It's not normal or acceptable that we can't all freely share documents with one another, no matter what operating system we like to use. We can send each other email, even if you are on Windows and I'm on Linux. Why isn't that the norm for everything? It ought to be. The bottleneck is Microsoft. FOSS software is happy to interoperate with any other software. Why won't Microsoft?
OpenXML wrap-up after D12K
~ by Georg C. F. Greve, Free Software Foundation Europe
Publication of my article "Novells
Danaergeschenk" on Groklaw.net
has spurred quite some interesting reactions, like this interview
with the Futurezone of the ORF, Austria's national public-service
broadcaster, titled "Streit ums
Dateiformat der Zukunft" ("Controversy about the file format of
the future" -- sorry, German only). But there was also a very lively
discussion on Groklaw with some very interesting and good
comments, some of which I'd like to pick up and/or reply to.
Many of the comments were focussed on exploring all the angles of
the problems caused by and related to OpenXML, such as:
Fidelity of implementation
comment points out that the article could also have highlighted a
very common practical problem: Even if the specification is commonly
known, the dominant player can easily introduce small
incompatibilities that will break interoperability for competitors,
strengthening the "Incompatibility is always the fault of the
competitor" mechanism that I outlined in the article.
This is indeed quite common, and Microsoft's
treatment of Kerberos is good evidence that such a behaviour can
be expected for OpenXML. As this
comment points out, Microsoft appears to have reserved the right
to take legal action against competitors that implement the actual
instead of the published specification. But that may not be the only
legal angle. Since the OpenXML format contains DRM "functionalities," this
comment fears there might be ways to bring up TRIPS/DMCA/EUCD-like
legislation against reverse engineering of the true format.
I did not examine these issues in depth for two reasons: I wanted
to keep the article as short and simple as possible and to keep it as
OpenXML specific as possible. That being said, there is significant
economic gain for the dominant player in "not quite" adhering to any
standard, and few sanctions for such behaviour. Precisely for this
reason establishing and maintaining Open Standards is so
In my view, this experience makes a strong point for mandating Free Software
reference implementation(s) as one of the criteria for Open Standards
in software, as I have also explained in my article "Sovereign
Software" for the first UN Internet Governance Forum
The only way to prevent this sort of thing seems to add one more
criterion to the definitions above: ''The standard must have at least
one Free Software implementation and all implementations that seek to
be compliant with the Open Standard must be regularly tested against
the Free Software implementation(s), which act as the common reference
Because Free Software is, inter alia, defined by the freedom to
study its implementation, this allows all players in the market to
study the common reference base not only in specification language,
but also in language, and regular tests against that base can help
curb deviations from the Open Standard.
Free Software also provides the freedoms of use, modification and
distribution, therefore most vendors can also simply include that
implementation in their own software, further reducing
More examples for wanting only one standard
As Groklaw reader Toby Thain points out in his
comment, the internet itself could also have served as an example
for why having more than one standard for any given purpose is
harmful. This is quite true and you might want to keep this in mind
for debates. In the article I avoided it deliberately, though, as I
sought to use an example that was closer to daily life for
Doing the math on OpenXML
This comment on
LWN.net points to a blog
entry by Andrew Shebanow of Adobe, titled: Is Office Open XML A
One-Way Standard? Ask Microsoft. Based on the article
by Microsoft's Rick Schaut that explains why the Mac version of
Microsoft Office will not support OpenXML until sometime next year,
Andrew Shebanow does the math and comes to the conclusion that
implementing OpenXML amounts to 150 work years.
In conclusion, Andrew Shebanow not only questions the economic
viability, but also voices scepticism about the chances for a truly
compatible implementation that maintains fidelity between the
implementations of different vendors. So overall it seems that Rick
Schaut has essentially confirmed the issues raised by IBM's
Bob Sutor about OpenXML being a one-way standard for migration to
Principles of standardisation
Another insightful comment was this explanation
by Diehl Martin about why Open Standards are important to break
the vicious cycles of forced upgrades.
There were also some comments that are better described as
related or follow-up articles, and very good ones at that. This anonymous
article deals with standardisation on a more philosophical level,
from the article:
I don't, however, think that it's
inappropriate to ask a vendor to change their software to comply with
a standard. Do we seriously give MS Office the standing of a national
language? The standing of English, or French, or Spanish, or Chinese,
or Japanese? Do we really have no right, in the standards process, to
ask Microsoft to change their software? Well, not so much change their
software, but to implement the standard the other way around - for MS
Office to implement the standard, not for the standard to implement MS
Office, which is obviously why it's 4000+ pages, and getting
Difference to .doc import?
Related is also this
comment that discusses how OpenXML (unlike ODF) has never been
meant to be a universal document format. Putting OpenXML up against
the Open Document Format is described as pure marketing spin, and
referring to OpenXML only being incremental change to the old ".doc"
and ".xls" formats.
The comment continues that importing an OpenXML file will be no
different from importing ".doc" and ".xls" files into OpenOffice or
some other program. In fact, I also received a few questions asking
why I consider it a good thing for OpenOffice.org to support reading
.doc files, while I disagree with the notion of adding OpenXML.
The answer is simple: The two questions have entirely different
backgrounds and situations. Before there was an ISO standard universal
document format, all applications had to try and support as many
formats as possible, because this was the only way to achieve
interoperability. And while there were some file formats that would
have allowed better interoperability, e.g. the Rich-Text Format (RTF),
they were not used by default by the dominating vendor. So writing
import/export filters for OpenOffice.org was the only way to get a
foot into the door, and has helped the technology field arrive at a
truly universal Open Standard: Open Document Format (ODF).
Now an Open Standard exists, is ISO certified and supported by many
different applications. It should be the only format used by
governments and companies -- for all of the reasons outlined in the Groklaw
article and this one. And while it is good to maintain support for
legacy formats from the time when there was no standard, including
".doc," adding support for OpenXML only serves to help undercut the
existing Open Standard by use of market power, technological tricks
and political efforts.
Of course some comments also suggested additional reading, such as
comment, which references an article by Nicholas
Petreley that is based on an Information
Week article by Cory Doctorow, discussing the wider picture in
which this debate is taking place.
Creating public discussion and awareness of a problem is often the
first step in solving it, but it is not sufficient. In the comments
there were several practical suggestions, which I'd like to support
and encourage people to participate in.
Support Open Document Format (ODF)
As several people have pointed out, constructively supporting the
use, spread, adoption and legislation for truly Open Standards, such
as the Open Document Format (ODF), is one of the most useful things
people can do. This includes using ODF yourself for cooperating online
with others, as this LWN.net
Funny enough, all of this brings to mind RMS' essay We Can
Put an End to Word Attachments of 2002, only that it would need
updating to recommend the Open Document Format, boiling down to: I am
very sorry, but I could not read your attachment because it was saved
in a format that my office could not read. Could you please resend the
document in the universal document format "Open Document Format"
(ODF), the international ISO standard for document exchange?
Naturally the message should be adapted to the situation, recipient
and context in order to have the right tone. If people feel attacked
or criticised for having used the "wrong" format, such reminders may
end up being counterproductive. But discarding the possibility of
changing social habits is no less counterproductive, and ignores
evidence to the contrary: Just ask all the people who are now sorting
their garbage for recycling and compare that to the position they took
30 years ago.
Support ODF plugin for Microsoft Office?
Although it might seem strange to suggest that anyone should
improve a Microsoft product, we should also consider the usefulness of
improving the ODF plugin. Making it very easy for all users of
Microsoft Office to interact via ODF would provide a major advantage
for ODF over OpenXML.
Community comments to the ISO process
on Groklaw proposes to turn the incorporated denial of service
attack that is OpenXML back on Microsoft by extensively commenting on
each of the 6000 pages of specification during the review process
prior to the ISO vote.
Preventing ISO acceptance of OpenXML could indeed be an important
step, and while one might have sufficient confidence in the ISO
process to work better than that of ECMA, some support on this side
might be very helpful.
Finally, I was (for the most part positively) surprised by the
interesting discussions that arose from my usage of the terms
"Danaergeschenk" and "Salomonian," including Bob Sutor making Danaergeschenk
the word of the day on his blog.
Although I think some people might have taken this a little too
seriously, there was some interesting discussion regarding my use of
"Danaergeschenk" in my article.
Some people felt that I should have used "Trojan Horse", which is a
common expression in both German and English, but that never really
occured to me for various reasons. I checked this
page for a translation of Danaergeschenk, and ruled out Trojan
Horse for various reasons: The Trojan Horse wasn't Trojan, it was
Greek, for which Danaer or "Danaos" is original Latin term. It also
isn't common to return horses to the stores around christmas. And as
some people right
pointed out, the terms have different connotations and
So after some consideration, I decided to go with "Danaergeschenk",
even though I knew this was entirely unknown to English speakers,
which is why it was briefly introduced in the beginning. Given that
words like "Fahrvergnügen" made it into English, I thought this
might prove to be a fun addition, even if people followed this
advice and simply called it D12K.
As far as "Salomonian" is concerned, I did not expect it to be that
difficult, as king Solomon is a very common reference in German. For
those who'd still like to know how it was meant, I believe this
comment explains it quite well.
I guess that usage of both these words are owed to my humanistic
education, which had me study Latin for six years. My apologies to all
who felt I subjected them to the pain of that education
The author is initiator and president of the Free Software Foundation Europe (FSFE)
and his personal
blog is available at the Fellowship
This work is licensed under a Creative Commons Attribution-ShareAlike 2.5 License.