OesterBlog

In den letzten beiden veröffentlichten Versionen von OpenOffice.org hat sich einiges getan im Bereich der Benutzerfreundlichkeit (engl.: Usability). Speziell die Tabellenkalkulation Calc hat überdurchschnittlich profitiert, wie man auf der Wiki-Seite Calc-Usability ToDo-Liste sehen kann. Natürlich ist noch viel zu tun – die Liste an offenen Punkten und Nutzerwünschen ist lang -, aber von Version zu Version steigern sich die Bemühungen der Entwickler, alte und/oder vielgewünschte Probleme und Verbesserungen anzugehen.

Meiner Meinung nach sah die Situation vor 2-3 Jahren noch nicht so rosig aus wie heute, was die Quantität der Bemühungen der OOo-Entwickler anging, auf Nutzeranregungen einzugehen. Die wurden damals mehr übersehen (oder übergangen?) als diskutiert. Da hat sich seither viel zum Positiven getan.

Das alles liegt sicher (auch) an der Arbeit des Teams des User Experience Projects (kurz UX) unter Führung von Frank Loehmann. Auf der eigenen UX-Website und im neuen UX-Team-Blog bündeln und zeigen Sie Ihre Arbeit. Neue Anstrengungen wie die Quaterly Reviews für Calc zeigen die Richtung vor, wie auch andere Teilprojekte von OpenOffice.org mit gebündelten Kräften an der Benutzerfreundlichkeit feilen können.

Falls jemand konkrete Anregungen haben sollte (oder gar Patches ;-), scheut euch nicht, es in IssueZilla (der Fehler- und Wunschdatenbank für OpenOffice.org) einzutragen oder bei bestehenden Einträgen zu kommentieren. Auch das UX-Team ist für Anregungen offen. Ich bin Frank Loehmann sehr dankbar, dass er sogar meine langen, langen Mails liest und kommentiert. Fehlt nur noch die Umsetzung. ;-)

Aber nicht nur in den UX-Seiten und in IssueZilla, sondern auch auf diversen Wiki-Seiten finden sich Ideen und Verbesserungsvorschläge wie z.B. im Abschnitt „Collection of Ideas“ der StartCenter-Seite, bei DirectManipulationSnippets oder die Zusammenfassung der Vorschläge eines Mailinglisten-Nutzers (ich finde die entsprechende Wiki-Seite nicht mehr).

Abschließend verweise ich noch auf OpenOffice.org 3.0, das im September 2008 mit vielen Verbesserungen erscheinen soll. Nach den UX-Listen zu urteilen, werden in 3.0 nicht mehr UX-Themen eingearbeitet sein als beispielsweise in 2.4 (die Calc-UX-Liste von 2.4 war wesentlich länger als die für 3.0 sein wird), dafür werden größere Projekte angegangen und Änderungen „unter der Haube“ im Writer wie die Mehrseitenansicht und der Zoom-Schieber, die verbesserte Notiz-Funktion oder die Arbeit am „separate core from layout“, das in Zukunft mehr Ansichten (wie die Normalansicht in MS Office) ermöglichen kann. Mehr Detailverbesserungen werden dann wieder in den Folgeversionen 3.x nachgereicht.

Heute bin ich über LXer.com auf einen Artikel beim International Herald Tribune gestoßen, der mich überrascht hat:

Microsoft to make Office open to ODF format

<Einschub am 24.05.2008>

• Offizielle Pressemitteilung von Microsoft
• Office 2007 soll das OpenDocument-Format unterstützen
• heise.de: Microsoft will offenes Dokumentenformat ODF unterstützen

</Einschub>

Das ist seit meinem Artikel IE8 voraussichtlich doch von Haus aus Webstandards-kompatibel mal wieder eine positive Nachricht von/über Microsoft. (Gibt es über das Standardverhalten des IE8 eigentlich neuere Informationen? Haben große Websites, die ihren Quältext nicht warten wollen, das neue Meta-Tag integriert?)

Um wieder zum eigentlichen Thema zurückzukommen: Der IHT-Artikel umreißt die Ankündigung Microsofts, Anfang 2009 eine kostenlose Erweiterung zur Verfügung zu stellen, die sich nahtlos in Microsoft Office 2007 integriert und im Gegensatz zum derzeitigen, eher schlechten als rechten Konverter von Microsoft ODF auch ermöglicht, als Standard-Dateiformat genutzt werden zu können.

Man wird sehen, wie weit die Interoperabilität mit OpenOffice.org (dann in Version 3.x mit ODF 1.2 *) besser funktioniert mit dem neuen (oder nur verbesserten?) Plugin von Microsoft. Man wird auch sehen, ob die Ankündigung überhaupt umgesetzt wird. Derzeit überschlägt sich Microsoft ja geradezu mit Interoperabilitäts-Beschwörungen. Der Druck durch die OpenSource-Welt, die EU und Behörden, die auf OpenOffice.org umsteigen, mag endlich Gehör gefunden haben. (Der Autor des IHT-Artikel fragt berechtigterweise, wieso das denn so lange dauert, bis der reichste Software-Konzern der Welt ein einfaches Plugin veröffentlichen kann.)

Ich hoffe zumindest, dass es nicht nur Beschwörungen bleiben. Und ich hoffe, dass beim Öffnen von ODF-Dokumenten MSO von selbst den Download des ODF-Plugins vorschlägt – wenn es schon nicht von Haus aus eingebaut ist. Aber das wird wohl wirklich ein Wunschtraum bleiben.

* Ein Fallstrick von Microsoft? OpenOffice.org wird dann gut ein halbes Jahr bereits ODF 1.2 unterstützen, während MS Office ODF 1.1 anbietet. Das bedeutet wieder Inkonsistenzen. Microsoft sollte in der OASIS darauf drängen, dass ODF 1.2 endlich fertiggestellt wird. Dann geht sich die Implementierung von ODF 1.2 noch locker aus.

PS vom 24.05.2008:
Südafrika legt offiziellen Protest gegen ISO-Normierung von OOXML ein

Als besonders ironisch bezeichnen Beobachter derweil die Tatsache, dass Microsoft nach all der an den Tag gelegten Eile im „Fast Track“-Verfahren zur OOXML-Normierung jüngst angekündigt habe, die nun angegriffene ISO-Norm [zu OOXML] frühestens 2010 im eigenen Office-Paket zu implementieren und zunächst einmal die konkurrierende ISO-Norm Open Document Format (ODF) zu unterstützen. – Quelle

Nachdem das Vertrauen in die Unabhängigkeit, den technischen Verstand und die Integrität der ISO und der nationalen Normungsorganisationen bei vielen gesunken oder geschwunden ist durch die Ungereimtheiten bei der Normung von Microsofts OOXML und der kurzfristigen Einflussnahme vieler Firmen (für beide Seiten) und vor allem Microsoft „Gold Partner“ (für OOXML) in den Normierungsprozess, klingt die Ankündigung der ISO wie ein Spott auf die letzten 16 Monate. Noch dazu klingt es reichlich hochgegriffen, wo die ISO es nicht mal geschafft hat, alle Kommentare zu OOXML einzeln zu bearbeiten und in die Norm einfließen zu lassen („Das wird zu einem späteren Zeitpunkt geschehen …“).

Ich werde keine Vermutungen anstellen, was bei dem Versuch der ISO, ODF und OOXML zusammen zu legen/zu harmonisieren herauskommen wird. Die Einflussnahme von Privatfirmen aus reinem Eigeninteresse in den Normierungsprozess hat es die letzten Monate zur Genüge gezeigt.

Mehr Vertrauen in das technische Können der Beteiligten, die Gleichberechtigung aller Parteien, der Offenheit des Prozesses und der Unabhängigkeit der Organisation bringe ich persönlich dem W3C oder der OASIS entgegen. Die verbringen ihre Tage nicht hinter verschlossenen Türen, sondern tüfteln öffentlich oder zumindest transparenter als ÖN, DIN und ISO.

Man muss einsehen, dass die Erarbeitung neuer Standards, besonders im IT-Sektor, etwas ganz anderes ist als die Harmonisierung von Gewinden oder die Sicherung von Feuerzeugen. Sowas können die Normungsorganisationen. Der IT-Sektor verlangt durch seine ungeheure Dynamik und den vielfältigen Wettbewerb nach raschen, offenen Prozessen, die zu offenen Protokollen und Formaten führen, die Weltweit von jeder Firma rasch umgesetzt werden können.

Andere haben es schon überall im Web verkündet (z.B. Heise.de, ubuntuusers.de). Was soll man noch dazu sagen. Ich war immer ein Freund von internationalen Normen, habe auch in der Arbeit viel mit Normen zu tun. Was aber die letzten 15 Monate bei der ISO, beim DIN und beim ÖN vor sich ging, hat meine positive Meinung zu diesen sonst so unparteiischen und objektiven Organisationen zerstört. Als OpenSource-/ OpenAccess-/ Webstandards-/ OpenDocument-Befürworter mag ich befangen sein, aber erklärt mir mal einer diese ganzen Ungereimtheiten überall auf der Welt, die durch die (kurzfristige) Einmischung Microsofts und seiner Gold-Partner in den Normierungsgremien geschahen. Die ISO hat ihre Reputation verloren.

ÖN

Allein die Arbeit des ÖN erscheint mir suspekt. Meine Frage zur Entscheidungsfindung und zu öffentlich zugänglichen Informationen beim ÖN wurde im September 2007 gar nicht beantwortet, nur mit der allgemeinen Aussage, dass Ecma 376 im Februar 2008 nochmal zur Abstimmung steht und dass ich eingeladen bin mitzuarbeiten, wenn ich denn ein Experte sei. Nichts über die Mitglieder, die zu OOXML abgestimmt haben, nichts über Abstimmungsverhalten, Diskussionsinhalte oder sonstiges. Alles fand hinter verschlossenen Türen statt, ein Kampf zwischen Microsoft-Partnerfirmen auf der einen und jenen von IBM, Sun und der OpenSource-Welt auf der anderen Seite. Man kann sich ausrechnen, welche Seite mehr Firmen, Geld und Lobbyisten hinter sich scharen konnte. Microsoft hatte viel zu viel zu verlieren, um bei der ISO abgewiesen zu werden.

Zukunft

Nun gut, andere sehen die Zukunft für OpenDocument und OpenSource mit dieser ISO-Entscheidung rosiger als ich, zum Beispiel Andy Updegrove mit The Future of ODF and OOXML (englisch).

Aber man wird sehen, wie weit die Kommentare bei der ISO noch abgearbeitet und in die Norm zu OOXML eingearbeitet werden (oder ob sie nun mangels Interesse versanden?).

Man wird sehen, ob Microsoft dieses neue OOXML am Ende in sein Office-Paket übernehmen wird (wenn überhaupt, dann wahrscheinlich erst mit der nächsten MS Office-Version; Besitzer von MS Office 2007 werden mit dem veralteten, falschen OOXML weiterarbeiten müssen und unzählige ungenormte, nicht zukunftsfähige und nicht interoperable Dokumente erstellen).

Man wird sehen, wie weit Microsoft das ISO-OOXML in seine Produkte integrieren wird. Wird es so enden wie jedes andere Mal in der Vergangenheit, wie zum Beispiel bei POSIX in den 90ern, dass Microsoft das Minimum an geforderten Kriterien umsetzen und den Rest unter den Tisch fallen lassen wird? Nicht-Microsoft-Produkte werden dann mangels Kompatibilität wie bisher bei .doc/.xls/.pps von den Kunden und Behörden nicht verwendet werden (können). Für Behörden wird das Argument reichen, dass „OOXML ja genormt ist“, um weiterhin teure MS Office-Versionen mit Steuergeldern anzuschaffen. Für andere Produkte und Betriebssysteme wird es hingegen schwer werden.

Schöne neue standardisierte Microsoft-Welt.

Ältere Artikel zum Thema in diesem Weblog:

• Bald OOXML-Abstimmung, ISO-Komitee lahm gelegt
• Die Probleme mit Office Open XML (OOXML)
• Accessibility Issues with Office Open XML
• Links zum Thema ODF gegen OOXML
• Suche nach Widersprüchlichkeiten bei OOXML

Nach einer Verzögerung ist OpenOffice.org endlich in Version 2.4 erschienen. Bei 2.3 habe ich im Blog selbst die wichtigsten Neuerungen präsentiert, heute lasse ich das lieber andere machen. Noch dazu, wo es so schön präsentiert wird. :)

OpenOffice.org Ninja präsentiert die Neuerungen von OOo 2.4.0, untermalt mit Bildschirmfotos und Videos.

Im OpenOffice.org-Wiki kann man sich die Kurzübersicht der wichtigsten Änderungen ansehen: OOo Features.

Für mich persönlich wichtig sind die neuen Funktionen: separate Zoom-Einstellung je Tabelle, das vereinfachte Kopieren und Verschieben von Zellen in Calc, die vereinfachte Sprachauswahl in der Statusleiste und dass mit Bild rauf und Bild runter nun im Calc auch neue Seiten angeschaut werden können (hört sich trivial an, ist aber wichtig für die Benutzerfreundlichkeit in Calc).

Zugleich mit OOo 2.4 ist auch das neue Website-Design präsentiert worden. Mir gefällt aber die englische Seite besser als die deutsche, die weniger aufgeräumt, zu bunt und viel zu breit wirkt.

Als Vorschau kann man sich bereits auf die Neuerungen in OpenOffice.org 3.0 (ausführlich bebildert; oder Testbericht lesen) freuen, das im Herbst 2008 erscheinen soll.

Schon seit Monaten ist es bekannt, leider tut niemand etwas dagegen: Nach der gescheiterten ISO-Abstimmung über OOXML (Ecma 376, ISO DIS 29500) am 2. September 2007 ist das für Dokumentenformate zuständige Komitee SC 34 bei der ISO lahm gelegt (z.B. Golem, ORF). Die meisten der extra kurz vor der damaligen Abstimmung dem Komitee beigetretenen ISO-Mitglieder verweigern seitdem die Mitarbeit. Da für eine gültige Abstimmung mindestens die Hälfte der Komiteemitglieder teilnehmen muss, ist das Komitee seitdem praktisch handlungsunfähig.

Dieses Verhalten der jüngsten Komiteemitglieder bestätigt die Ansicht vieler Beobachter, dass diese Staaten bloß eingetreten sind, um Microsofts OOXML durchzuwinken. Wer sie überredet oder bezahlt hat, das zu tun, sei dahin gestellt. Die Frage ist, was tut die ISO dagegen? Ich habe noch von keinen Aktivitäten gehört, die dieses lächerliche aber äußerst bedenkliche Trauerspiel bei der ISO beendet oder korrigiert. Ich nehme an, es wird auch nichts geschehen. Zu groß sind die wirtschaftlichen Interessen am schnellen Durchwinken von Firmenstandards hin zu internationalen Normen. Die ECMA ist dafür die perfekte Tarnung Plattform.

Wie geht es nun weiter? Ende Februar ist die 2. Abstimmung zu OOXML. Bis dahin müssen alle Bedenken ausgeräumt werden, die bei der letzten Abstimmung zum Scheitern geführt haben. Die ECMA hat dazu bereits ein 2.300 Seiten langes Papier veröffentlicht. Man wird sehen, ob sich die Staaten, die negativ gestimmt haben, mit den Änderungen zufrieden gestellt werden. Die Kritik an OOXML und an den Änderungen verhallt jedoch nicht.

Problematisch aus Sicht eines Österreichers finde ich das Verhalten des österreichischen Normungsinstituts zu OOXML. Wo gibt es eine offizielle Stellungnahme zum Abstimmungsverhalten auf der ÖNORM-Website? Wer sind die stimmberechtigten Mitglieder des ON-Komitees ON-K 001 „Informationsverarbeitung“? Wer hat wie abgestimmt? Wer wird von wem dort hin geschickt und bezahlt? Das ÖN hat dazu nie irgend etwas gesagt, sogar den ORF lässt man mit unbeantworteten Fragen zurück (bis heute). Anfang September habe ich diesbezüglich eine E-Mail an die ÖN geschickt. Zurück kam bloss die Antwort, wenn ich als Experte mitarbeiten wolle, solle ich mich doch mit einem offiziellen Aufnahmeverfahren bei der ÖN anmelden.

Ich nenne es besser beim Wort: Demokratiepolitisch ist das Verhalten der ÖN eine Schande. Wo ist die Transparenz? Wo wird die Entscheidung erläutert und begründet? Wird hier nur hinter verschlossenen Türen abgestimmt zwischen „Experten“? Ich bezweifle offen die Unabhängigkeit dieser sogenannten Experten.

Wer am Laufenden zu diesem Thema bleiben will, muss sich im Web selbst umsehen. Von offizieller Seite (ISO, ÖN, …) gibt es so gut wie nichts darüber zu lesen. Das Blog Rob Weir von IBM oder jenes von Anwalt Andy Updegrove (ConsortiumInfo.org) sind beispielsweise gute kritische Informationsquellen.

Seit Jahren habe ich darauf hingearbeitet. Zuerst kam die Umstellung auf Firefox 1.0. Dann folgte der Schwenk von MS Office XP auf OpenOffice.org 2.0. Dann wagte ich die Migration von MS Outlook XP auf Thunderbird 1.5 (später mit der Kalendererweiterung Lightning vervollständigt). Schließlich ersetzte ich all meine proprietäre Software unter Windows durch Gegenstücke aus der Welt der freien Software (FOSS).

Was habe ich daraus gelernt? Es gibt Gutes und Schlechtes über FOSS-Produkte zu sagen, aber sie funktionieren.

Der schwierigste Schritt ist, seinen inneren Schweinehund zu überwinden, etwas zu wagen und neue Software auszuprobieren. Darum habe ich relativ spät mein E-Mail-Programm gewechselt, in der Arbeit überhaupt erst seit kurzem.

Im nächsten Schritt muss man seine erlernten Arbeitsweisen – wie etwas zu funktionieren hat – und seine gewohnten Vorstellungen – was alles zu funktionieren hat – anpassen. Das mag schmerzhaft sein. Aber genau so wie man die vorherigen Programme mit der Zeit zu beherrschen gelernt hat, wird man auch die neuen nach einer Weile beherrschen.

Ich würde sowieso jedem einen Betriebssystem- und Office-Grundkurs empfehlen. Ich kenne praktisch niemanden, der mit beidem wirklich professionell umgehen kann. Jeder Chef und jeder Kollege setzt voraus, dass man ein Windows und ein MS Office bedienen kann. Dem ist aber nicht so. Ich brauche nur den Sekretärinnen über die Schulter zu schauen, und mir wird übel, wenn ich deren chaotisches Arbeiten beobachte. Dabei müssten die es am besten können! Von anderen Kollegen ganz zu schweigen, die schon fragen müssen, wie man die Ordneransicht umschaltet, oder die sofort nervös werden, wenn Symbole anders aussehen (ein typisches Ergebnis, wenn Leute nicht geschult werden und sich notdürftig selbst helfen). Alter spielt übrigens keine Rolle. Junge wie alte Leute können gleich schlecht mit Software umgehen. Mit dem Alter wird nur die Lernkurve etwas langsamer.

Darum, egal ob man bei Microsoft verharrt oder auf Linux und OpenOffice.org umsteigt, rate ich jedem zu einer Schulung. Mein Vater macht gerade eine, und das Arbeiten mit dem Rechner beginnt ihm nun erst richtig Spaß zu machen.

Aber ich bin abgeschweift.

Worauf habe ich Jahre hingearbeitet und nun endlich Zeit gefunden?

Auf meinen Umstieg auf die GNU/Linux-Distribution Ubuntu 7.10. Dazu komme ich im nächsten Artikel.

Die Schlappe von Microsoft ist noch nicht lange her. Das neue Dateiformat von Microsoft Office 2007, OpenXML (OOXML), wurde im Schnellverfahren bei der ISO als internationale Norm abgelehnt. Nun folgt die Fehlerbehebung seitens Microsoft (oder besseres Marketing und kosmetische Korrekturen ohne wirkliche Fehlerbehebung, man wird sehen) und frühestens im Februar 2008 kommt es zur nächsten Abstimmung, bei der es dann wirklich heißt: durchgewunken oder weg vom Fenster.

Wie dieses Spiel auch immer ausgehen mag (denn dieser ISO-Prozess ist zum Spiel verkommen; man lese sich diverse Heise-Artikel und sonstige Publikationen im Netz über OOXML und die seltsamen Vorgänge in den nationalen Normenorganisationen durch). Eines ist sicher: Das nächste Dateiformat, das 2008 zur ISO-Abstimmung kommen wird, ist OpenDocument (ODF) 1.2, das derzeit noch bei der OASIS den letzten Schliff bekommt.

Die Hürde für ODF 1.2 wird um ein Vielfaches höher liegen als 2006, als ODF 1.0 offiziell als ISO-Norm anerkannt wurde. Wieso? Für die Antwort muss man kein Hellseher sein.

Erstens gibt es heute mehr ODF-Kritiker als früher.

Die Anzahl der stimmberechtigten Staaten und die Anzahl der stimmberechtigen Mitglieder in den einzelnen nationalen Normenorganisationen hat exorbitant zugenommen. Wie oben bereits erwähnt, gibt es zu diesen Vorgängen genug Artikel im Netz zu finden. Die Auswirkung davon ist aber eine, die Rob Weir in einem seiner Blog-Beiträge als Grafik sehr anschaulich illustriert: How to Hack ISO vom 4. September 2007, Diagramm über die Verteilung von „Approval/Disapproval“-Stimmen bei der ISO.

Dieses Diagramm zeigt, dass während des ISO-Schnellverfahrens für OOXML die Zahl der Befürworter stark angestiegen ist (analog zur Zunahme neuer Mitglieder; Altmitglieder haben mehrheitlich gegen OOXML gestimmt; siehe die Tabelle in Rob Weirs Blog-Beitrag). Viele Microsoft freundlich gestimmte Firmen und Partner von Microsoft sind den nationalen Normenorganisationen beigetreten und haben zu mehr Gewicht für OOXML beigetragen. Zusätzlich, und das ist das Ausschlaggebende, haben eine ganze Reihe von Staaten einen Antrag auf Stimmberechtigung bei der ISO angefordert. (Nicht alle Staaten sind bei einer Normenabstimmung stimmberechtigt. Diese Berechtigung muss man sich vorher holen, um den sogenannten P-Status zu erhalten.) Alle diese neuen P-Staaten sind Dritte Welt- oder relativ arme Staaten wie die Elfenbeinküste, Syrien und Kasachstan und fast alle von ihnen haben (überraschenderweise?) für OOXML gestimmt.

Es ist davon auszugehen, dass diese Staaten dann gegen ODF 1.2 stimmen werden, da sie ja beigetreten sind, um OOXML zur Norm zu verhelfen.

Zweitens gibt es heute überhaupt ODF-Kritiker.

Als ODF 1.0 zur Abstimmung vorgelegt wurde, gab es keine Gegenstimmen oder technische Mängel, die behoben werden mussten. Das lag wohl daran, dass man eine Norm für Dokumentformate als nicht sonderlich wichtig nahm. Microsoft hat dies im Nachhinein natürlich ins Fleisch geschnitten, als Staaten anfingen zu fordern, dass Daten in Dateiformaten abgespeichert werden sollten, die ISO-genormt sind.

Heute, nach vielen Schlachten für und gegen OOXML, gibt es auch haufenweise Kritiker und Geschäftsleute, die gegen ODF wettern. Egal ob OOXML dann Norm ist oder nicht, ODF 1.2 wird es nicht mehr so leicht haben wie früher.

Drittens wurden die Anforderungen an OOXML hoch gelegt.

An OOXML werden hohe Anforderungen gelegt (zumindest von Staaten, die „Nein mit Kommentaren” gestimmt haben), was Interoperabilität, Zugänglichkeit, Implementierbarkeit, Zusammenarbeit mit anderen Standards usw. angeht. Die selben Anforderungen werden dann auch für ODF 1.2 gelten. Man wird sehen, ob die ODF-Arbeitsgruppen wirklich gründlich und unabhängig gearbeitet haben, wenn die Kritiker mit dem Suchen von technischen Mängeln oder Abhängigkeiten zu Sun-Produkten in ODF 1.2 beginnen.

Die Hürde für ODF 1.2 wird größer sein, wenn OOXML als ISO-Norm scheitert, und kleiner, wenn OOXML doch noch zur Norm wird. Darum wundert es nicht, dass Sun Microsystems (der Hauptproduzent und Schirmherr von OpenOffice.org und OpenDocument) die Normierung von Microsofts OOXML befürwortet.

Die letzte Zeit konnte man viel über DIS 29500, so der Name in der Technischen Arbeitsgruppe bei der ISO, bzw. Office Open XML lesen. Wirklich positive Berichte kommen dabei – außer bei Microsofts Vertragspartnern – aber nicht vor. Was liest man zusammenfassend hier und dort über OOXML?

1. Nicht vollständig implementierbar
2. Nicht interoperabel
3. Nicht barrierearm
4. Nicht vollständig konvertierbar
5. Inkonsistent
6. Erfindet viele Räder neu
7. Fehlerhaft
8. Nicht händisch veränderbar
9. Schwammig formuliert
10. Nur für Microsoft Office geschaffen

Nicht vollständig implementierbar

Es ist für Nicht-Microsoft-Programmierer praktisch unmöglich, die Spezifikation vollständig umzusetzen. Der Umfang der Dokumentation mit seinen 6.000 Seiten erschlägt einen mit Arbeit. Alter Ballast aus vorigen proprietären Microsoft-Dateiformaten ist in die neue Spezifikation undokumentiert übernommen worden und lässt einen im Ungewissen, was beispielsweise autoSpaceLikeWord95 oder truncateFontHeightsLikeWP6 bedeuten soll. Bezugnahmen auf proprietäre Technologien wie Windows Meta File Format, Microsoft-spezifische Namensräume oder Abhängigkeiten zu bestimmten Versionen des Internet Explorers machen die Spezifikation Windows-lastig und nicht mehr unabhängig, offen und frei dokumentiert. (Unter anderem die PDF-Datei des dänischen Normungsinstituts zum Thema DIS 29500 zeigt eine ganze Reihe solcher Mängel auf.)

Nicht interoperabel

Mit Interoperabilität meint Microsoft die (exklusive) Zusammenarbeit mit älteren Microsoft Office-Formaten und nicht die eigentliche Bedeutung von Interoperabilität, nämlich den Austausch von Information zwischen verschiedenen Anwendungen und Formaten ohne Einschränkungen. Da zudem in den OOXML-Endnutzerverträgen das Reverse Engineering alter MS Office-Formate untersagt wird, wird eine vollständige Implementation der Spezifikation (die in Teilen auf undokumentierten, alten MS-Technologien aufbaut und ein Reverse Engineering notwendig macht) und die Interoperabilität anderer Programme mit Microsoft Office verhindert. (Siehe dazu Kommentare von Fachanwalt Michael Schinagl von der Kanzlei BDHSW auf heise.de.) Unflexible Nummernsysteme machen OOML zudem inkompatibel mit einigen regionalen Nummernsystemen und sie widersprechen denen von W3C XSLT und Unicode ISO 10646.

Nicht barrierearm

Das Adaptive Technology Resource Centre der Faculty of Information Studies der Universität von Toronto hat ein detailliertes Papier herausgegeben, das die Zugänglichkeit von OOXML für benachteiligte Personen bezweifelt. Siehe dazu den Artikel Accessibility Issues with Office Open XML und den vollen Bericht des ATRC.

Nicht vollständig konvertierbar

Es ist nicht so einfach wie bei OpenDocument möglich, Konvertierungswerkzeuge für OOXML zu bauen. Die einfachste Art, Konverter für Daten mit XML-Strukturen zu bauen, ist mittels XSLT-Transformatoren. Doch OOXML unterstützt die dafür notwendige Technologie XPath nicht vollständig fehlt es an der nötigen „XPath-perfekten” XML-Struktur, damit XSLT reibungslos funktioniert, weshalb der XSLT-Transformator von Microsoft/Clever-Age/Novell schlicht unzureichend arbeitet.

Inkonsistent

In weiten Teilen der Spezifikation wird immer noch das veraltete VML anstatt des neueren DrawingML benutzt, obwohl es in der Spezifikation selbst als veraltet/misbilligt beschrieben wird. Noch dazu besitzt DrawingML nicht alle Möglichkeiten von VML, weshalb VML nicht nur zum Zweck der Abwärtskompatibilität in OOXML weiterhin gebraucht wird. Auch Textformatierungen sind inkonsistent aufgebaut, da sie je nach Office-Programm (Word, Excel, PowerPoint) verschiedene Bezeichnungen haben. In OpenDocument (ODF) dagegen sind Formatierungen immer gleich, egal in welchem Programmteil Text verwendet wird. Sogar Prozentangaben werden auf verschiedene Weise inkonsistent in OOXML dargestellt.

Erfindet viele Räder neu

Anstatt bestehende und bewährte Technologien und Normen zu verwenden, erfindet Microsoft in OOXML vieles unnötig neu und verkompliziert so die Implementierung und die Lesbarkeit der Spezifikation. Statt VML/DrawingML könnte SVG genutzt werden. Statt der eigenen Papiergrößen-Bezeichnungen wäre ISO 216 zu bevorzugen. Statt der unleserlichen Zahlenkolonnen in OOXML müsste ISO 8601 verwendet werden, um Datum und Zeit abzuspeichern. Der OOXML-eigene Hash-Algorithmus sollte zugunsten bestehender und bewährter (wie zum Beispiel von FIPS 180) als missbilligt deklariert werden. Statt eigens erfundener Farbbezeichnungen sollten das SVG- oder ISO/IEC 15445-HTML-Farbschema übernommen werden. Sprach- und Ländercodes nach ISO 639 würde jeder verstehen statt der OOXML-eigenen Codes. Auch bei Graphics Metafiles geht OOXML einen eigenen Weg, anstatt ISO 8632 zu nutzen.

Fehlerhaft

Alter Microsoft-Ballast macht OOXML nicht nur nicht vollständig implementierbar, sondern normt auch alte Microsoft-Programmierfehler und nimmt sie so mit weit ins 21. Jahrhundert hinein. Das krasseste Beispiel dafür ist die Missachtung des gregorianischen Kalenders beim Arbeiten mit Kalenderdaten, wo das Jahr 1900 fälschlich als Schaltjahr gerechnet wird, was auch Konsequenzen beim Datenaustausch mit anderen Programmen hat. Sicherheitskritisch ist die Tatsache, dass man eine passwortgeschützte Excel-Tabelle wieder beschreibbar machen kann, indem man einfach das Element sheetProtection mit einem Texteditor aus dem OOXML-Code entfernt.

Nicht händisch veränderbar

Einer der wichtigsten Vorteile von gepackten XML-Daten, nämlich dass man sie per Hand mit einem Texteditor nachbearbeiten kann, trifft auf OOXML nicht zu. Excel-Kalkulationen kann man nicht so einfach nachträglich per Texteditor ändern. Denn viele Abhängigkeiten zwischen verschiedensten OOXML-Teilen machen eine klitzekleine Änderung zum Spießrutenlauf und im schlimmsten Fall (und das geht schnell) wird das Dokument für Excel unbrauchbar. Stéphane Rodriguez hat dies nachgewiesen. Eignet sich so ein Format, das per Texteditor ohne detaillierte Kenntnisse zum Dateiformat selbst nicht leicht zu ändern ist, als Speicherformat zur Langzeitarchivierung von Daten (zum Beispiel wenn kein geeignetes Programm mehr zum Verarbeiten des Dokuments vorhanden ist)?
Noch ein Vorteil von XML ist die leichte Lesbarkeit der Elemente und Attribute für Mensch und Maschine gleichermaßen. OOXML ist aber mit seinen Elementen wie scrgbClr oder rPr weder konsistent noch für Menschen lesbar gestaltet.

Schwammig formuliert

Verweise auf bestimmte Versionen von Normen und Spezifikationen (Unicode, EMF, WMF, XML, XML Schema, XPath, XSL, ZIP, ASCII Characters, …) fehlen, was viele verschiedene, zueinander inkompatible Implementierungen zur Folge haben wird. Oder anderes Beispiel: Mehrere Financial Functions verweisen auf eine „day count basis”, die nicht näher beschrieben ist.

Nur für Microsoft Office geschaffen

Die Marketingmasche mit open by design kommt spätestens dann jedem unglaubwürdig vor, wenn man weiß, wann Microsoft OOXML öffentlich zugänglich gemacht hat: Nämlich erst als MS erkannte, dass sich mit OpenDocument (ODF) von der OASIS ein offenes Dokumentenformat erfolgreich und unaufhaltsam (langsam aber stetig) seinen Weg durch Normungsgesellschaften, Behörden und die OpenSource-Gemeinschaft bahnt. Um dem fortschreitenden Erfolg von ODF entgegen zu wirken, wurde OOXML veröffentlicht und mit dem Prädikat „offen” versehen, dann der ECMA vorgelegt, die es ohne eingehende Begutachtung oder Änderungen als ECMA 376 akzeptiert hat, und dann zur ISO weitergeleitet.

Und ist OOXML schon vorher als offen konzipiert worden? Dinesh Nair vom Open Malaysia-Blog war beim Microsoft Summit 2007 und hat von einem Microsoft-Manager die technische Wahrheit über OOXML erfahren: … the file format (OOXML) was a part of the software and that OOXML and the software (MS Office) are quite inseparable. Ergo, OOXML is an integral and inseparable part of MS Office. That’s why they could not adopt ODF as the file format for subsequent versions of MS Office. … (Zitat aus Open Malaysia) Mit so einer Aussage eines Microsoft-Insiders müssten sich eigentlich alle weiteren Bemühungen der ISO erledigen. Soll ein Dateiformat, das von einer einzigen Firma speziell für ein einziges Produkt entworfen wurde und von ihm nicht zu trennen ist, als internationale Norm verabschiedet werden?

Zudem existiert noch keine einzige ECMA 376-Implementation. (ECMA 376 entspricht DIS 29500 bei der ISO.) OOXML von MS Office 2007 weicht vielerorts von ECMA 376 ab, weshalb davon auszugehen ist, dass ECMA 376 bzw. DIS 29500 nicht ausreichend ist, um andere Programme mit MS Office 2007 vollständig kompatibel zu machen.

Update 2007-09-18: Am 10. September 2007 wird Brian Jones von Microsoft bei computerworld.com mit den Worten zitiert: It’s hard for Microsoft to commit to what comes out of Ecma in the coming years, because we don’t know what direction they will take the formats. We’ll of course stay active and propose changes based on where we want to go with Office 14. At the end of the day, though, the other Ecma members could decide to take the spec in a completely different direction. … Since it’s not guaranteed, it would be hard for us to make any sort of official statement. Man darf sich also nicht darauf verlassen, dass Microsofts OOXML-Weiterentwicklungen die selben sein werden wie die der Ecma – geschweige denn der ISO.

Diese Informationen sind aus unzähligen Quellen seit Monaten zusammengetragen und wurden noch nicht durch technische Beweise entkräftet. Einige besonders umfangreiche Quellen sind die dänische Normungsorganisation DS mit ihrer 64-seitigen Kritik, Heise in diversen Artikeln (als kurze Zusammenfassung diverser Veröffentlichungen meist gut zu lesen) wie dem über juristische Unklarheiten und restriktive Endnutzerverträge, Stéphane Rodriguez mit seinen erschreckenden, fundierten technischen Analysen von OOXML mit MS Office 2007, das Technical Distinctions of ODF XML and OOXML-Dokument der ODF Alliance European Action Group sowie die lange Liste der EOOXML objections von grokdoc.net.

Persönlich finde ich es sehr unwahrscheinlich, dass Microsoft alle technischen Mängel, wie sie von den nationalen Normenorganisationen vorgelegt wurden, abarbeiten und in DIS 29500 umsetzen wird. Erstens wären das ein enormer Arbeitsaufwand (allein schon wegen VML und DrawingML), der nicht in wenigen Wochen oder Monaten zu bewerkstelligen ist, ohne dass sich Fehler und Schlampereien einschleichen. Zweitens wäre das ein Eingeständnis seitens Microsoft, dass die Gegner von OOXML recht hätten und diese Spezifikation wirklich qualitativ zu schlecht und überarbeitungswürdig sei. Drittens müsste MS Office 2007 dem überarbeiteten DIS 29500 angepasst werden, sonst kommt es zu Inkompatibilitäten zwischen MS-eigenen OOXML-Dateien und jenen aller anderen. – Von den nichttechnischen Mängeln wie Patente ganz abgesehen, die bei der ISO sowieso nur unzureichend behandelt werden.

Update 2007-09-18: Abschnitt Nur für Microsoft Office geschaffen erweitert.

Seit OpenDocument 1.1 im Frühjahr bei der OASIS als offizielles Dokument verabschiedet worden ist, habe ich die Mailinglisten der ODF-Macher verfolgt und bin etwas kritischer geworden, was die Entwicklung der Interoperabilität von ODF angeht.

Was ist Interoperabilität?

Das ist im Falle von ODF die Möglichkeit, verschiedene Programme zum Erstellen, Bearbeiten und Speichern von Dokumenten zu benutzen und nicht angewiesen zu sein auf ein bestimmtes Programm.

Wie schafft man Interoperabilität bei einem Dateiformat?

Wenn bei der (Weiter-)Entwicklung von ODF 1. die Unabhängigkeit von bestimmten Programmen und Firmen gewährleistet ist und 2. möglichst viele daran mitwirken (Einzelpersonen, Firmen, Organisationen und Behörden).

Der 1. Punkt ist durch die OASIS eigentlich gegeben, aber Sun Microsystems spielt immer noch die bestimmend(st)e Rolle bei der Weiterentwicklung von ODF (welches ein Ableger ihres älteren OpenOffice.org 1.0-Dateiformats darstellt). Punkt 2 mag ebenfalls durch die OASIS abgedeckt sein, da jedes OASIS-Mitglied sich an der Entwicklung beteiligen, Vorschläge einbringen und mitdiskutieren kann. Und jede Firma kann OASIS-Mitglied werden. Aber die Materie ist komplex und nur wenige Personen haben das Wissen, eine umfangreiche Spezifikation wie ODF (mitsamt den damit verknüpften Techniken XML, RDF, SVG, …) zu verstehen und daran mitzuwirken. Wenn man die offiziellen Mailinglisten verfolgt, so sieht man großteils nur wenige Personen weniger Firmen wie Sun, IBM, Novell, Trolltech/KDE.

Gut, diese Gegebenheiten sind an sich nichts Schlechtes. Zu viele Köche verderben den Brei. Sun fördert aktiv die Weiterentwicklung von ODF. IBM leistet zum Beispiel mit Robert Weir hervorragende Arbeit bei der Ausarbeitung der Spezifikation für Formeln/Tabellenkalkulationen, die in seiner vollständigen Form erstmals offiziell Teil von OpenDocument in Version 1.2 sein wird. Außerdem beruhigt die Anwesenheit von KDE-Entwicklern, die die reibungslose Zusammenarbeit mit Linux-Umgebungen und eine zweite (vollständige) Referenz-Implementierung von ODF, nämlich in KOffice, sicherstellen.

Aber jede dieser Firmen hat natürlicherweise Eigeninteressen, die es auch innerhalb der OASIS-Spezifikation gewahrt wissen will. Zwei Beispiele: Sun will ODF weiterhin abgrenzen gegen Microsofts OOXML. Die OpenDocument-Foundation will ODF zu einem wahren Austauschformat machen und fast perfekte Wiedergabetreue (perfect fidelity) und Interoperabilität (interoperability) erreichen, um Dateikonvertierungen von und zu ODF (speziell mit Microsofts OOXML und DOC/XLS/PPT) reibungsloser als bisher zu ermöglichen.

Hürden für Interoperabilität

Die im vorigen Absatz angeschnittenen Eigeninteressen der ODF-Macher (die legitim sind) schaden OpenDocument bei der Verbreitung mehr als sie helfen, zumindest quantitativ gesehen. Sun möchte natürlich seinen OpenOffice.org-Ableger StarOffice an den Mann bringen und das kostenlose OpenOffice.org weiter verbreiten. Das geht aber nur, wenn es sich abgrenzt von MS Office und der Dateiaustausch nur beim Import reibungslos funktioniert, OpenDocument aber nicht als verlustfreies Austauschformat zwischen Suns Office und MS Office dient. Denn dann könnte ja jeder bei MS Office bleiben und trotzdem OpenDocument verwenden. (In die gleiche Kerbe schlägt Sun mit der Planung, nur einen OOXML-Importfilter für OpenOffice.org 3.0 zu entwickeln und keinen gleichwertigen Exportfilter.)

Das Interesse der OpenDocument-Foundation ist vorhin schon skizziert worden: ODF als verlustfreies Austauschformat zwischen verschiedenen Programmen. Das widerspricht natürlich dem Wunsch von Sun (als Ganzes; persönliche Interessen von Suns Mitarbeitern kenne ich nicht) bezüglich OpenOffice.org. Reibungslose Interoperabilität ist aber nur gewährleistet, wenn Programme Daten aus ODF-Dateien verlustfrei importieren und exportieren können.

Interoperabilität besitzt noch nicht die nötige Priorität in den OpenDocument- Arbeitsgruppen, weshalb ODF noch nicht wirklich und nachdrücklich zum Durchbruch verholfen werden konnte. Die Verantwortung für Interoperabilität wird eher auf die Software-Ebene geschoben als sich damit innerhalb der ODF-Spezifikation genauer zu befassen. Fakten gefällig?

1. Florian Reuter machte in seinem Blog im November 2006 eine Auflistung von Anpassungen, die ODF 1.2 seiner Meinung nach benötigen könnte und die Zusammenarbeit mit MS Office-Dateiformaten erleichtern sollten. (Er ist Mitarbeiter von Novell, und Novell hat mit Microsoft einen Pakt geschlossen, Konverter für OOXML<>ODF zu programmieren.) Praktisch nichts davon wurde in der Arbeitsgruppe aufgegriffen, wie er vor kurzem erläuterte.
   In der Mailingliste wurde ein abweisender Kommentar dazu abgegeben. Kurz umrissen: Man werde ODF nicht verändern, nur um mit Funktionen von MS Office-Dateiformaten besser umgehen zu können, für die es in ODF noch keine Entsprechung gibt. Und die Bemerkung, man solle seitens Novell doch ein paar Änderungen am Microsoftschen OOXML-Format vorschlagen, klingt zynisch, da doch jeder in der Mailingliste weiß, dass Microsoft niemals sein Format wegen äußerer Vorschläge ändern wird. Der abweisende Kommentar kam von Sun, und man kann aus Suns Sicht verstehen, dass in OpenDocument nichts stehen soll, was es nicht auch in OpenOffice.org gibt (man könnte ja später von Sun fordern, diese ODF-Funktionen auch in OpenOffice.org einzubauen). Diese Abwehrhaltung widerspricht aber dem Gedanken von OpenDocument als anwendungsunabhängiges Dateiformat. Zusätzlich hilft diese Abwehrhaltung auch nicht, ODF als Austauschformat bei Behörden durchzusetzen, da es der ODF-Arbeitsgruppe offensichtlich am Willen fehlt, auch Fremdprodukte zu unterstützen und eine reibungslose Konvertierung zu ermöglichen. (Darum das Versagen in Massachusetts, siehe nächster Punkt.)
2. Die IT-Abteilung der Verwaltung von Massachusetts plante 2006 den Umstieg auf OpenDocument (nicht auf OpenOffice.org/StarOffice) mithilfe von daVinci/InfoSet. Die Bemühungen von Massachusetts scheiterten aber unter anderem an den Anpassungen, die an OpenDocument hätten vorgenommen werden müssen, um den schon angesprochenen reibungslosen Austausch zwischen ODF und anderen Dateiformaten (in beide Richtungen!) zu gewährleisten. Gary Edwards schrieb dazu einen Kommentar auf meine Frage hin, ob es denn einen Zeitplan für die Fertigstellung von daVinci gäbe.
   Aufgrund der fehlenden, von der ODF-Arbeitsgruppe nicht aufgegriffenen Anpassungen von ODF, ohne die es keine reibungslose Konvertierung geben kann, wurde in Massachusetts (wie auch in anderen US-Bundesstaaten und Dänemark) entschieden, dass auch OOXML als offiziell anerkanntes Dateiformat gelten darf. Somit hat ODF die wichtige Unterstützung von Behörden verloren, die zur Verbreitung und öffentlichen Akzeptanz von ODF geführt hätten.
   Ich frage mich persönlich, wie dies Sun als gewinnträchtige Firma hilft in seiner Verbreitung von StarOffice, wenn ODF in Zukunft nicht mehr in Betracht gezogen wird, weil es sich nicht gut genug in den täglichen Arbeitsprozess von Behörden/Firmen einfügen lässt.
3. Die allgemeine Ablehnung gegen Anpassungen von ODF hinsichtlich Kompatibilität zu MS Office/OOXML mag auch mit einer Abstimmung zusammenhängen, bei der IBM und andere dagegen stimmten, Konformität von ODF mit einem Format einer einzelnen Firma herzustellen (erwähnt in einem Archiv-Kommentar). Das hört sich eigentlich vernünftig und nach einem hehren Ziel an. Zumindest für weniger verbreitete Produkte; es gäbe auch zu viele davon, um alle zu berücksichtigen. Aber wenn die Mehrheit der weltweiten Anwender von Büro-Software Funktionen nutzt, die in ODF nicht implementiert sind oder nicht verlustfrei umgewandelt oder zumindest erhalten werden können (für einen späteren Export aus ODF heraus und deren Wiederverwendbarkeit), wieso sollten diese dann umsteigen auf ODF, wenn ihre Dateien dadurch Schaden nehmen oder aufwändig nachbearbeitet werden müssen?
4. Interoperabilität mit anderen ODF-Programmen und anderen Dateiformaten wie OOXML und UOF scheint auf ODF nach Version 1.2 hinausgeschoben zu werden, wie hier, hier und hier (letzter Absatz zu ODF 1.3) als Beispiel nachzulesen ist. Doch kann es sein, dass alle Behörden und Firmen schon auf OOXML umgestiegen sein werden, bevor ODF 1.3 im Jahr 2008 oder 2009 das Licht der Welt erblickt.
5. David A. Wheeler, der Vorsitzende der ODF-Unterarbeitsgruppe für Formeln/Tabellenkalkulation hat in einem Kommentar angeregt, die Liste der unzureichenden oder fehlenden Funktionen der beiden Dateiformate des ODF-Konverters von Microsoft durchzugehen und auf Fehler im Konverter und möglicherweise neu in ODF (oder OpenOffice.org) zu implementierende Funktionen zu prüfen. (Nebenbei erwähnt Wheeler noch, untermauert durch Beispiele, dass OOXML laut dieser Liste viel eingeschränkter sei als ODF. – Im Frühjahr, als ich mir die Websites des ODF-Konverters von Microsoft angesehen habe, kam mir auch schon der Gedanke, dass diese Liste eine perfekte und schnelle Vorlage wäre für Anpassungen von ODF oder OpenOffice.org.) Aber leider: Analog zur Ablehnung in den vorherigen Beispielen gab es auch hier keine einzige Reaktion dazu in der Arbeitsgruppe und keine weiteren Schritte hin zu einem besseren Universaldateiformat.
6. Apropos Universaldateiformat: Sun möchte gewährleisten, dass OpenDocument von möglichst vielen unterschiedlichen Anwendungen korrekt nach den Vorgaben der Spezifikation verwendet werden kann. Das heißt natürlich, dass es so wenig wie mögliche Vorgaben, Einschränkungen oder Beschränkungen geben darf, damit ja möglichst viele Anwendungen alles implementieren können, nicht nur Office-Programme. Die Folge: Alle Absätze in der Spezifikation, bei denen es um bestimmte Elemente, fremde Inhalte („alien elements”) oder Metadaten geht, die man für die Interoperabilität mit anderen Programmen bewahren müsste, werden schwammig oder locker formuliert. Zum Beispiel darf ein Programm alle Metadaten löschen und ist trotzdem konform mit der Spezifikation (in Folge davon fehlen einem anderen Programm, mit dem man die Datei weiterverarbeiten will, wichtige Daten).
   Ein Dokument, in dem eine Reihe von zuvor noch vorhandenen Vorgaben für Software-Hersteller aus ODF gelöscht werden, ist das OpenDocument 1.2 File Format Change Proposal – Issues List Metadata Model vom 3. Juli 2007. Man lese selbst Abschnitt 1.20, 1.22 und 1.23.

Mehrere Konformitätskriterien

Marbux, ein Mitglied der ODF-Mailingliste, hat in einem Beitrag vorgeschlagen: Wenn man denn schon eine sehr offene Dokumentennorm haben will, solle man zwei Konformitätskriterien erstellen; eines für Softwareentwickler, die ihre Programme für die Einweg-Verarbeitung von ODF-Dateien optimieren (also nur für den Import oder Export von OpenDocument-Daten, sinnvoll zum Beispiel für Grafik- oder Desktop-Publishing-Programme wie Inkscape oder Scribus), und eines für jene, die ihre Programme für den Import und Export optimieren und einen möglichst verlustfreien Austausch von Daten gewährleisten wollen. (Office-Pakete passen klassischerweise zu zweiterem, da sie nicht der Abschluss eines Bearbeitungsprozesses sind und Daten danach nicht endgültig archiviert, sondern woanders weiterverarbeitet werden.)

Es steht außer Frage, dass die Vorgaben, dass bestimmte oder ODF-fremde Inhalte und Metadaten nicht gelöscht werden/bewahrt werden sollen, näherer Klärung bedürfen (wann darf es doch geschehen, was bedeutet es für Software-Hersteller genau usw.). Mehrere ODF-Arbeitsgruppenmitglieder stehen strikteren Vorgaben aus diesen technischen Überlegungen entgegen, wie zum Beispiel Robert Weir in einem Mailinglisten-Beitrag schreibt.

Auch andernorts gibt es heftige Diskussionen, z.B. bei ODF-Fellowship, ob es überhaupt wünschenswert sei, Microsofts fremde Elemente in ODF unterzubringen und damit perfekte Wiedergabetreue zu gewährleisten. Dazu wurde von Daniel Carrera vorgeschlagen, die ODF-fremden Elemente von Microsofts OOXML in OOXML-Form einzubinden und nicht in kryptischer Binärform. Eine ODF-Datei wäre immer noch konform der Spezifikation, auch wenn sie OOXML-Elemente beinhaltet.

Damit ODF nicht ein ähnliches Schicksal wie TIFF erleidet und durch Erweiterungen bestimmter Programme/Firmen nicht selbst inkompatibel/inoperabel wird, muss unter anderem das Einbinden fremder Elemente auf jene beschränkt werden, für die es keine Entsprechung in der ODF-Spezifikation gibt, wie Daniel Carrera vorgeschlagen hat. Dazu müsste aber in Abschnitt 1.5 der Spezifikation das Wörtchen SHOULD in MUST NOT geändert werden: „There are no rules regarding the elements and attributes that actually
have to be supported by conforming applications, except that
applications should not use foreign elements and attributes for features
by the OpenDocument schema. See also appendix D.” – Auch andere Abschnitte der ODF-Spezifikation müssten wohl strenger geregelt werden, um ein Inkompatibelwerden von ODF zu unterbinden.

Wie auch immer es ausgeführt werden kann/soll: Als Konsens sollte die Grundrichtung stimmen, dass ein Dokumentenformat mit den hohen Ansprüchen wie OpenDocument bessere Interoperabilität mit verbreiteten Dateiformaten gewährleistet, als es bis heute der Fall ist. Wie auch immer das möglich wäre – und wie auch immer das möglichst rasch möglich wäre mit schnell zu entwickelnden Werkzeugen, um den Markt dafür zu decken.

Software-Ebene oder Dokumentenebene?

Eine weitere berechtigte Frage ist, ob man solche Konformitätskriterien oder striktere Vorgaben überhaupt in einer Spezifikation unterbringen oder ob man diese eher den Software-Herstellern überlassen soll. Office-Hersteller mögen sicherlich Zweiteres bevorzugen und sagen, lasst doch den Markt entscheiden; niemand lässt sich schließlich gern etwas vorschreiben. Aber wie so oft bringt es der Mehrheit der Anwender mehr, wenn gewisse Spielregeln vorgegeben werden, damit nicht bestimmte Gruppen bevorzugt werden oder egoistische Wünsche auszuleben überhand nimmt. Mit verschiedenen Konformitätskriterien wären Vorgaben besser in der Spezifikation untergebracht als sie dem guten Willen der Software-Hersteller auszuliefern. Damit wäre Interoperabilität auch objektiv überprüf- und bewertbar. Der Acid2-Test hat der Browser-Landschaft erst die nötige Unterstützung für wichtige Teile der CSS-Spezifikationen abgerungen. Das selbe wird für ein interoperables ODF nötig sein.

Kommt die Interoperabilitäts-Arbeitsgruppe?

Am 6. Mai 2007 stellte Robert Weir von IBM die Frage einer künftigen Interoperabilitäts-Arbeitsgruppe nach der Verabschiedung von ODF 1.2. Besonders die UOF-Arbeitsgruppe, die sich mit der Zusammenarbeit/Konvertierbarkeit von ODF und der chinesischen Dokumentennorm UOF beschäftigt, interessiert sich sehr für mehr Interoperabilität. Dies macht Hoffnung für ODF 1.3, aber wie schon gesagt: Dann könnte der Zug für OpenDocument schon abgefahren sein.

Was könnte diese Arbeitsgruppe tun?

1. Interoperabilität zwischen ODF-Anwendungen, egal ob es sich um traditionelle Programme wie OpenOffice.org, KOffice usw. oder um webbasierte Editoren wie Google Docs & Spreadsheets handelt.
2. Interoperabilität zwischen ODF und anderen Markup-Sprachen wie MathML, XForms usw.
3. Interoperabilität zwischen ODF und anderen hochspezialisierten Dokumentformaten wie DocBook, DITA oder UOML.
4. Praktische Vorschläge für die Interoperabilität zwischen ODF und Mikroformaten wie vCard oder Creative Commons-Lizensierung .
5. Interoperabilität zwischen ODF und anderen Dokumentformaten von Microsoft, Corel, Lotus usw.

Und was hat das mit mir zu tun?

Nun, ich will das, was wahrscheinlich die allermeisten Kunden möchten (und ich gehe davon aus, dass ich hier wirklich den Wunsch der Mehrheit aller Office-Anwender ausdrücke): Nicht daran denken zu müssen, welches Dateiformat sie benutzen. Wenn ich in meiner Firma ODF als Standarddateiformat durchsetzen will, darf es für Anwender nicht sichtbar werden, dass sie eine Datei anders abspeichern als vorher. Technisches und Ideologisches interessiert die Leute nicht. Es muss egal sein, ob sie Microsoft Office, Lotus Notes oder OpenOffice.org verwenden – es darf beim Speichern und Öffnen von OpenDocument-Dateien keine Rolle spielen.

Doch es spielt derzeit noch eine Rolle, mit welchem Programm man arbeitet. Sogar zwischen OpenOffice.org und KOffice gibt es Inkompatibilitäten, die erst noch aus dem Weg geräumt werden müssen, also zwischen zwei Programmen, die ODF als Standarddateiformat implementiert haben.

Keine Zweifel

Doch neben all meiner Kritik möchte ich keine Zweifel darüber aufkommen lassen: OpenDocument ist offener, zugänglicher, flexibler, unabhängiger und einfacher als das Konkurrenzformat OOXML, das derzeit bei der ISO diskutiert wird. Wer seine Daten hersteller- und betriebssystemunabhängig und zukunftssicher zur Weiterverarbeitung speichern will, kommt an ODF im Bereich Büro-Software nicht vorbei. Da mögen Werbekampagnen, FUD und Lobbyarbeiten der Konkurrenz noch so viel Gegenteiliges in die Welt setzen.

OpenDocument 1.0 war der Grundstein und die gemeinsame Basis aller beteiligten Parteien. OpenDocument 1.1 legte seinen Fokus auf Zugänglichkeit. OpenDocument 1.2 wird Formeln/Tabellenkalkulationen und Metadaten-Angaben perfektionieren sowie viele kleine Verbesserungen bringen wie Tabellen in Präsentationen und standardisierte digitale Signaturen. Wenn Hersteller von ODF-fähigen Programmen in Zukunft vermehrt auf Interoperabilität schauen (und zum Beispiel OpenOffice.org beim Importieren keine Metadaten und ihm fremde Elemente löscht), müssten wir nicht mal mehr auf OpenDocument 1.3 warten, dessen größte Aufmerksamkeit hoffentlich der Interoperabilität gilt.

Das Adaptive Technology Resource Centre der Faculty of Information Studies der Universität von Toronto hat ein detailliertes Papier herausgegeben, das die Zugänglichkeit mit dem Dateiformat OOXML behandelt.

Wofür steht das ATRC?

… The ATRC supports open standards …
We are strong advocates of the overlooked principle that people with disabilities should be producers and not only consumers of information, knowledge and culture. …

Welchen Schluss zieht das ATRC bezüglich OOXML?

There are grave issues with respect to the accessibility of Office Open XML as a format and potential standard that should preclude its adoption at present. It may be the case that OOXML can be improved to ameliorate some of the more specific technical concerns, but it is most likely too late for the higher-level issues, especially those inherent in the process by which OOXML was developed. We suggest that energy would be better spent in the ongoing effort to improve the existing ISO ODF standard (with which OOXML would overlap and compete if it is adopted). In any event, decisions with respect to standardized document formats should be made in consultation with members of disability communities, disabilities experts and developers of assistive technologies, with universal accessibility as a core requirement as opposed to an ad hoc afterthought.

Der volle Bericht ist hier nachzulesen:
Accessibility Issues with Office Open XML vom 07. August 2007.

Die letzte Version OpenOffice.org 2.2.1 hat nur Fehler bereinigt aber sonst keine Neuerungen/Verbesserungen gebracht. Mit der nächsten Version 2.3 ist dies anders. 42 neue Funktionen und 212 Fehlerbereinigungen oder Funktionsverbesserungen wurden die letzten Monate eingebaut. (Die OOo-Wiki-Seiten Feature Freeze Testing 2.3 und die New Features 2.3 geben detailliertere Auskunft über die eingebauten Veränderungen.)

Die Fülle an verschiedensten Verbesserungen und Neuerungen zeigt, dass das Konzept aufgeht, alle 6 Monate eine neue x.y-Version zu veröffentlichen und zwischendurch alle 3 Monate ein x.y.z-Bugfix-Release (ohne Neuerungen). Für OpenOffice.org 2.4 sind auch einige Dinge in Planung, wie man zum Beispiel auf Seiten wie der OOo-Wiki-Seite Features (für die großen Projekte) oder der OOo-Wiki-Seite Calc Usability Activities (Verbesserungen der Benutzerfreundlichkeit in Calc) nachlesen kann.

Wie man sieht, tut sich einiges in der OpenOffice.org-Gemeinschaft.

Und was tut sich Neues bei OOo 2.3?

• Allgemein: neuer Java-Installationsassistent für Unix-Systeme
• Allgemein: verbesserte Unterstützung für komplexe Tabellen
  (Beispielbild auf GullFOSS)
• Allgemein: Auswahl der Vorlagengruppe nun gleichbleibend je Anwendung (Writer, Calc, …)
• Allgemein: verbesserte Lokalisierungen und neue Sprachen verfügbar
• Allgemein: Datei>Eigenschaften>Allgemein>Ort nun markierbar zum Kopieren
• Allgemein: den letzten Befehl wiederholen mit Strg+Umschalt+Y nun möglich
• Allgemein: die in einem Dokument gespeicherten Drucker-Einstellungen können ignoriert werden (um zum Beispiel Fremddokumente besser ausdrucken zu können)

• Writer: zentrierte Ansicht und Zoom von Dokumenten
  (Beispielbild auf GullFOSS)
• Writer: Vorschau von HTML-Dokumenten im bevorzugten Browser aus Writer heraus möglich
• Writer: MediaWiki-Export für Dokumente in UTF-8 (ermöglicht das Erstellen von Wiki-Seiten direkt in Writer bzw. Writer/Web)
• Writer: die Aktualisierung von Diagrammen erfolgt nun automatisch direkt nach dem Bearbeiten einer damit verknüpften Tabellenzelle
• Writer: neue automatische Sprachenauswahl bei unbekannten Texten (Vorstufe zur verbesserten Sprachauswahl in OOo 2.4 über die Statusleiste)
• Writer: die ODF 1.1-Funktion Soft Page-Break wurde eingebaut (sichtbare Seitenumbrüche werden direkt im Dokument gespeichert, damit andere ODF-Programme wissen, wo der Umbruch bei der Dokumenterstellung vorgesehen war)
• Writer: neue Kompatibilitätseinstellung „Expand word space on lines with manual line breaks in justified paragraphs“, die wie in OOo 1.x ermöglicht, dass innerhalb von Blockabsätzen die Zeile vor dem Zeilenumbruch, wenn sie mit Umbruch+Eingabe erstellt wurde, nicht als Blocksatz formatiert wird

• Calc/Diagramm: vollständig neu programmiertes und erweitertes Diagramm-Modul („Chart2”, Auflistung der neuen Funktionen mit Bildbeispielen)
• Calc/Diagramm: vereinfachter Diagramm-Assistent
• Calc/Diagramm: gesprengte 3D-Rundsegmente (3D Pies Offset) als neuer Diagrammtyp verfügbar (bisher war nur 2D möglich)
• Calc/Diagramm: erneuerte Vorgabefarben für Diagramme

• Calc: automatisches Umwandeln des ersten Buchstaben in einen Großbuchstaben am Beginn von Zellen wurde deaktiviert, wenn kein Satz eingegeben wird, sondern nur Wörter oder einzelne Zeichen (Stichwort Benutzerfreundlichkeit)
• Calc: nur das ausgewälte Tabellenblatt wird per Voreinstellung in der Vorschau angezeigt und gedruckt, nicht mehr alle Tabellenblätter (Stichwort Benutzerfreundlichkeit)
• Calc: leere Seiten werden per Voreinstellung nicht mehr in der Vorschau angezeigt oder gerdruckt
• Calc: neue Fehlermeldung beim Versuch, eine leere Tabelle/einen leeren Tabellenbereich zu drucken (Stichwort Benutzerfreundlichkeit)
• Calc: verbesserte Summenfunktion (Stichwort Benutzerfreundlichkeit)
• Calc: die Tastaturkürzel Strg+Plus und Strg+Minus fügen ein oder löschen nun Zellen/Spalten/Zeilen wie die entsprechenden Menü-Einträge (Stichwort Benutzerfreundlichkeit)
• Calc: GETPIVOTDATA-Funktion implementiert

• Base: neuer Report-Designer (Berichts-Assistent)
• Base: Benutzeroberflächen für Formulare und Berichte sind nun von Writer unabhängig (Fenstergrößen, Symbolleisten usw.)

• Impress: Move along curve wieder verfügbar gemacht (war in OOo 1.x noch enthalten)
• Impress/Draw: HTML-Export unterstützt PNG-Grafiken für Präsentationen
• Draw: neue Alternativtexte für Image-Maps und Zeichenlayer (Stichwort Zugänglichkeit)

Die Neuerungen mit dem Stichwort Benutzerfreundlichkeit sind dem Dokument Calc Usability Activities entnommen. Eine Erklärung dazu gibt es im GullFOSS-Blog.

Hoffentlich gibt es in Version 2.4 auch wieder viele Verbesserungen in Punkto Benutzerfreundlichkeit und wieder einige neue Funktionen (Notes2 wird davon die bedeutendste sein).

Erscheinen wird OpenOffice.org 2.3 im September 2007, Version 2.4 dann im Frühjahr 2008 auf de.openoffice.org.

Rob Weir hat in seinem Blog (das es immer wert ist, gelesen zu werden), eine anschauliche und übersichtliche Zeitlinie erstellt, die die Entwicklung von (Office-)Dateiformaten der letzten 10 Jahre zeigt. Gegenüber gestellt sind Microsofts Produkte auf der einen und offene Standards auf der anderen Seite. Jeder Kommentar außer „die Vergangenheit wiederholt sich immer wieder “ erübrigt sich. Liest selbst in A File Format Timeline.

Auch das Open Malaysia Blog hat des öfteren sehr informative Beiträge über Dateiformate (ODF und OOXML) zu bieten. Is VML in or out now, or was that a typo? (wird OOXML mit dem nächsten MS Office wieder über den Haufen geworfen?) und Billions of Documents (über die Marketing-Lüge mit den „Milliarden von binären Office-Dokumenten“) und Day 1, Microsoft Technology Summit 2007 (ein Microsoft-Techniker gibt zu, dass OOXML nie als öffentlicher Standard konzipiert war) sind zum Beispiel solche Artikel.

Und wenn ich schon dabei bin, gibt es noch 2 Aufrufe zum Thema:

Bis OpenOffice.org 3.0 im Herbst 2008 erscheinen soll, werden noch einige größere Projekte fertiggestellt und in OOo 2.x eingebaut. Dazu gehören das neue Diagrammmodul für Calc, der Report-Designer für Base und Notes2 für Writer, das einen einfacheren Umgang mit Notizen ermöglichen soll.

Und was kommt mit OOo 3.0?

Neben den allgemeinen Arbeiten der Entwickler, die OOo 3 schneller, modularer und leichter zu warten machen sollen, gibt es einige große Projekte, die OOo 3.0 besser machen als seine Vorgänger. (Die Liste ist noch nicht fix, und es kann vieles dazukommen oder auch einiges wegfallen bzw. sich auf frühere oder spätere Versionen verschieben.)

• Die Änderungen von OpenDocument (ODF) 1.2 sollen umgesetzt werden, was bessere Zugänglichkeit/Barrierearmut von Dokumenten, bessere Zusammenarbeit mit den neuen MS Office-XML-Dokumenten und bessere Zusammenarbeit mit anderen Programmen gewährleistet, die ebenfalls OpenDocument verwenden. Außerdem gehört der neue Abschnitt über Tabellenkalkulationen zu ODF 1.2 (OpenFormula), der OpenDocument, KOffice und anderen Programmen nun ermöglicht, ein in Dokumentenebene völlig offenes, „interoperables“ und freies Excel-Pendant fertigzustellen. (Ohne die Fehler des Excel-Formats.)
  Zum Glück sind es noch anderthalb Jahre bis OOo 3 erscheint, denn die Entwicklung von ODF 1.2 ist die letzten Monate langsamer geworden. Der Erscheinungstermin von ODF 1.2 war im Herbst 2007 angepeilt, was nun wohl nicht mehr realistisch ist. (Warum die Arbeit nicht schneller voran geht ist mir ein Rätsel und ein Ärgernis im Hinblick auf die Konkurrenzsituation mit OOXML. – Mir brennt es in den Fingern, ein ODF-Arbeitsgruppenmitglied dazu zu befragen.)
• Das ODF-Toolkit soll anderen Programmen den Umgang mit OpenOffice.org bzw. dem OpenDocument-Format erleichtern.
• Bibliographic enhancements
• Unterstützung für Tabellen im Präsentationsmodul Impress
• Verbesserungen für Impress wie das Anzeigen von Notizen oder von Vorschaubildern der vorherigen und nächsten Seiten während einer Präsentation am Bildschirm des Vortragenden (nicht jedoch am Ausgabegerät für die Zuseher)
• Verbesserungen für Writer wie Vorschau von Hyperlinks innerhalb eines Dokuments oder einen ODF-Metadaten-Editor
• Verbesserungen für Calc wie die GETPIVOTDATA-Funktion oder das oben angesprochene OpenFormula
• Importfilter für MS Office 12 (Das mag nun keine „gute“ [als Gegenteil von „böse“] Neuerung sein – wo bleiben die guten Importfilter von Microsoft für ODF? – ist aber unumgänglich für die Weiterverbreitung von OOo.)
• Verbesserte Verwaltung von Erweiterungen (Extension enhancements)
• Möglicherweise besserer Umgang mit Microsofts VBA
• Verbesserte Integration in Windows Vista wie ein neuer Dateidialog und das Anzeigen von Metadaten im Explorer

Was fehlt?

Bis zum Veröffentlichungstermin von OpenOffice.org 3 werden sicherlich noch viele kleinere und größere Projekte zur Liste der neuen Funktionen/Verbesserungen hinzukommen. Was bisher jedoch fehlt ist – wegen seiner großen Bedeutung – die von den Entwicklern einmal angedachte Verbindung von OOo mit Mozilla Thunderbird (E-Mail) und Mozilla Sunbird/Lightning (Kalender). Mag aber sein, dass dies erst mit OOo 4.0 verwirklicht werden wird, was mehr als schade wäre.

Verfolgen kann man die offizielle Liste unter wiki.services.openoffice.org/wiki/Features.

Gary Edwards denkt in seinem Open Stack-Blog genau richtig: Die Antwort, um das OpenDocument-Format (ODF) weltweit zum Durchbruch zu verhelfen, liegt allein darin, dass Microsoft Office-Anwender und alle Produkte, die mit MS Office zusammenarbeiten, ODF als Standardformat anwenden oder zumindest damit umgehen können.

Dieses Problem wird seiner Meinung nach – und da schließe ich mich an – bisher viel zu wenig aufgegriffen. Mit Konvertern allein ist dies nicht zu schaffen. Erstens sind die Konverter von Microsoft/Novell und Sun zu unzuverlässig, um damit Dokumente zwischen MS Office und anderen Programmen produktiv austauschen zu können. Zweitens bleiben alle Produkte, die auf MS Office aufbauen oder sich daran anschließen, von den Konvertern unberührt – sie erzeugen wieder binäre Microsoft-Dateien oder OOXML-Dateien.

All dies geht die OpenDocument Foundation mutig an, um das Monopol von Microsoft zu brechen. Nicht um des Monopols willen, sondern zum Wohl und der Langlebigkeit des geistiges Eigentums der Dokumenten-Ersteller. (Würde sich Microsoft selbst 100%ig an alle Spezifikationen halten, die es mitentwickelt oder kreiert, wäre dessen Formate-Monopol weniger tragisch. Glaubt jemand eigentlich wirklich, dass OOXML, das Microsoft der Ecma vorgelegt hat, exakt das selbe ist, wie es in MSO 2007 implementiert wurde? Oder dass jemand anderes als Microsoft OOXML vollständig umsetzen kann?)

Die Antworten dafür lauten:

• daVinci ODF-Plugin und
• daVinci InfoSet Engine & API.

Das daVinci ODF-Plugin für Microsoft Office 98-2007 habe ich bereits vorgestellt, ist (angeblich) bereits bei der Verwaltung in Massachusetts als Testversion mit ODF v1.0 im Einsatz und soll mit Hilfe der Erweiterungen von ODF v1.2 noch im Jahr 2007 seine Perfektion und Marktreife erlangen.

InfoSet soll eine vollständige ODF-Konvertierungs- und Darstellungsanwendung werden, an der sich andere Produkte anstöpseln können, um mit ODF einfach arbeiten zu können (ähnlich dem ODF Toolkit Project von OpenOffice.org). Ein Veröffentlichungstermin dafür ist (leider) noch nicht bekannt. Die Arbeiten sind noch im Anfangsstadium.

Probleme mit der endgültigen Version von MS Office 2007

Interessant ist noch die Bemerkung von Gary Edwards, dass das Verhalten gegenüber ZIP-Dateipaketen in der endgültigen Version von MS Office 2007 anders sei als das in vorherigen Beta-Versionen. Microsoft hat anscheinend in letzter Sekunde die Systemeinstellungen so geändert, dass jedes ZIP-Dateipaket (wie ODF und OOXML eines sind) bei Doppelklick automatisch vom Microsoft’schen Konverter umgewandelt und in MS Office 2007 dargestellt wird. Somit werden alle nicht-microsoftschen Konverter (wie daVinci oder der von Sun) übergangen. Dieses Problem auszumerzen verzögert die Entwicklung von daVinci weiter.

Microsoft erklärt ODF und OOXML für Sieger

Vor ein paar Tagen hat Microsoft bzw. OOXML-Mitentwickler Brian Jones beide Dateiformate als Sieger klärt im „Formatekrieg“, nachdem Novell die erste Testversion seines OOXML-Konverters für seine eigene OpenOffice.org-Version veröffentlicht hat. Die Erklärung von Brian Jones finde ich a) witzig (denn noch ist gar nichts endgültig entschieden) und b) erheiternd (denn wenn Microsoft jemand anderen als sich selbst ebenfalls als Sieger bezeichnet anstatt als Verlierer, dann heißt das eigentlich, dass sich Microsoft selbst als (nahen) Verlierer sieht).

Novells Konverter dürfte übrigens auf wenig Gegenliebe in der OpenSource-Welt stoßen, denn er ist genau so schlecht wie der ODF-Konverter von Microsoft und baut auf Mono auf, einer OS-Variante von Microsofts .NET, anstatt das in OpenOffice.org bereits verwendete Java oder andere Techniken zu verwenden.