OOXML macht(e) der ISO zu schaffen. Darum wurden nun ein paar Änderungen im Verfahrensweg hin zu einer neuer Norm vorgenommen, damit so ein Schlamassel wie bei OOXML nicht mehr passiert. Robert Weir und andere berichten darüber ausführlicher.

Meiner Meinung nach sind da vernünftige Verbesserungen dabei wie z.B., dass bei einer Abstimmung nur mehr mit Ja, Nein oder Nein mit Kommentaren abgestimmt werden darf und nicht mehr wie bisher auch mit Ja mit Kommentaren. Bei OOXML hat sich gezeigt, dass sich auch nach mehreren Jahren nicht um diese Kommentare gekümmert wird, wenn die Norm bereits verabschiedet worden ist. Das ist so wie mit EU-Beitritten: Vor einem EU-Beitritt kann man dem Beitrittskandidaten alles Mögliche und Unmögliche vorschreiben und er setzt es um. Ist dieser Staat aber einmal beigetreten, ist es mangels Sanktion(smöglichkeit)en vorbei mit der weiteren Umsetzung der EU-Vorschriften.

Wenn ein Land an einem Normenvorschlag zukünftig etwas auszusetzen hat, kann nur noch mit Nein mit Kommentaren abgestimmt werden oder man winkt die Norm eben so durch, wie sie ist, und akzeptiert die Mängel.

Mit den jetzigen Änderungen wäre OOXML nie auf diese schnelle Weise zur Norm erhoben worden.

Rob Weirs Blog ist immer mal wieder gut zu lesen, wenn man sich für ODF interessiert. Immerhin ist er einer der treibenden Kräfte von IBM hinter ODF.

Ein paar Online-Magazine haben des Themas ODF 1.2 Begins Final 60-day Public Review in Roberts Blog aufgegriffen und darüber berichtet: Vor kurzem hat die öffentliche Begutachtung von ODF 1.2 begonnen. Wenn das abgeschlossen ist (nach spätestens 75 Tagen), gibt es eine Abstimmung innerhalb der OASIS, ob ODF 1.2 zur offiziellen OASIS-Norm werden darf. Wenn alles erfolgreich verläuft, wird ODF 1.2 noch im 4. Quartal 2010 der Arbeitsgruppe ISO/IEC JTC1 übergeben, die für die Normierung von ODF zuständig ist. Möglicherweise wird dann noch 2011 ISO/IEC 26300 mit ODF 1.2 die bisherige Norm aus dem Jahr 2006 mit ODF 1.0 ablösen.

Natürlich vorausgesetzt, dass keine schwerwiegenden Fehler mehr gefunden werden oder sich keine von bestimmten Firmen gesponserte Normeninstitutsvertreter quer stellen.

Das Kuriose an der Sache ist, dass bereits ODF 1.1 den Normierungsprozess durchläuft und auch irgendwann 2011 bei der ISO/IEC verabschiedet wird: Introducing ISO ODF 1.1. Wobei ODF 1.1 eigentlich nur als Novellierung von ODF 1.0 anzusehen ist. ODF 1.2 ist dagegen ein vollständiger und erweiterter Ersatz der bisherigen Norm. Durch die parallele Normierung (Aktualisierung) von ODF 1.1 wird langsamen Implementierern wir Microsoft der Boden entzogen, in deren Produkten auf die älteste ODF-Norm in Version 1.0 zu beharren anstatt auf ODF 1.1 oder dem noch nicht veröffentlichten ODF 1.2 zu setzen.

ODF 1.1 bringt eigentlich nur kleine Zugänglichkeitsverbesserungen. ODF 1.2 hingegen bringt eine bis ins Detail spezifizierte Formelsprache (OpenFormula) mit sowie viele neue Funktionen und einen eigenen Paketierungsabschnitt, den auch andere XML-Formate wiederverwenden könnten.

Derjenige, der maßgeblich daran beteiligt war, Microsofts OOXML als Norm in den ISO-Gremien wortwörtlich durchzudrücken, hat sich nun zu Wort gemeldet – 2 Jahre, nachdem DIS 29500 in einem umstrittenen Verfahren abgesegnet worden ist.

Um was geht es? Ich habe früher schon darüber berichtet:

  1. Microsofts OOXML ist durch
  2. Bald OOXML-Abstimmung, ISO-Komitee lahm gelegt
  3. Die Probleme mit Office Open XML (OOXML)
  4. Accessibility Issues with Office Open XML
  5. Links zum Thema ODF gegen OOXML
  6. Suche nach Widersprüchlichkeiten bei OOXML

Außerdem gibt es auch bei Rob Weir manchmal einen interessanten Beitrag dazu wie z.B. Asking the right questions about Office 2010’s OOXML support.

Komödie oder eher Tragödie

Nun, diese Nachricht von Alex Brown ist wenig überraschend und Microsofts Verhalten war vorherzusehen. Die ganze Geschichte mit der Normierung von Microsofts internem Dateiformat für sein Office-Paket war so offensichtlich aufgezogen, dass man es von Anfang an nicht anders deuten konnte als eine Schmierenkomödie – falls man kein Lobbyist für Microsoft war oder von einem solchen geblendet worden ist.

Das kommt eben heraus, wenn man ein (vormals oder vermeintlich) unabhängiges Normengremium von einer Firma öffentlich missbrauchen lässt.

Der Vorteil für Microsoft liegt auf der Hand: Sie haben das Argument gegenüber Kunden gewonnen, ein genormtes ISO-Dateiformat anbieten zu können (natürlich stimmt das nicht, da Microsoft Office eben nicht das ISO-genormte OOXML verwendet, sondern seine eigene Abwandlung davon; aber das wissen die Kunden ja nicht).

Und der Vorteil für die ISO? Es gibt keinen. Falls es jemals einen gegeben hat (vielleicht mehr Aufmerksamkeit von Seiten der Wirtschaft auch abseits der Schraubenhersteller), so wurde er längst durch den in eingeweihten Kreisen zerstörten guten Ruf und Microsofts Verhalten in den letzten 2 Jahren neutralisiert.

Fazit für MS Office

Microsoft Office 2010 wird kein korrektes ISO 29500 verarbeiten und speichern können. Auch 2 Jahre nach der Verabschiedung des hauseigenen Dateiformats nicht. Es gibt zugegebenermaßen einige Abweichungen von Microsofts ursprünglichem Vorschlag in der Norm, aber in 2 Jahren muss ein großer Konzern doch in der Lage sein, einen angeblich so einfach zu implementierbaren Standard und die darin enthaltenen Änderungen durch die ISO in das eigene Produkt zu übernehmen.

Microsoft Office kann auch nicht anständig mit ISO 26300 (ODF) umgehen. 2008 gab es noch Hoffnungen diesbezüglich, aber die haben sich verflogen. Robert Weir hat das letztes Jahr eingehend untersucht: 1. Artikel, 2. Artikel über Microsoft Excels Zerstörung von ODF-Formeln. Offensichtlicher kann man eine konkurrierende ISO-Norm nicht torpedieren und für Kunden unattraktiv machen.

(Das erinnert mich alles ein wenig an Microsofts Vorgehen bei der Umstellung der Londoner Börse auf Windows-Server: Microsoft hat das werbewirksam für sich ausgeschlachtet und die Konkurrenz verbal niedergemacht. Dass London kurze Zeit später wieder weg von Windows und auf Linux umgestiegen ist, wie übrigens alle großen Börsen der Welt, wird natürlich totgeschwiegen. Microsofts Konkurrenz hat keinen werbewirksamen Gewinn davon, da sie nicht die Marktmacht und die Geldmittel wie Microsoft besitzen.)

Nachdem ich erst kürzlich das Schullinux nach Kremser Art gefunden habe, offenbart sich mir ein weiteres Linuxprojekt für österreichische Schulen: desktop4education.

Als Teil des EU-Aktionsplans i2010 wolle man den Einsatz von Open Source Software an österreichischen Schulen fördern, schreibt das Ministerium den Direktoren in einem Begleitschreiben. Der Plan sieht vor, ab 2010 das Geld für die Lizenzen von Office-Software an Schulen zu streichen, ab 2012 will man auch keine Kosten für Betriebssysteme mehr tragen. Deshalb planen inzwischen immer mehr Schulen den Wechsel zu Open Office und Linux.

Wenn das wirklich stimmt, wäre das eine gute Sache – weg vom Konzern- hin zu offenerem Denken. Nur allein der Glaube daran fehlt mir. Und sei es, dass Microsoft die Lizenzen dann eben herschenkt.

Auf die weitere Entwicklung bin ich jedenfalls gespannt.

Seit kurzem ist das Servicepack 2 für Microsoft Office 2007 fertig und kann von der Microsoft-Website heruntergeladen werden. Ich und sicher viele andere haben lange auf diesen Augenblick gewartet: endlich native Unterstützung des genormten OpenDocument-Dateiformats durch ein Microsoft’sches Hauptprodukt.

Angekündigt wurde die neue Interoperabilitätswelle seitens Microsoft vielerorts (wie in ODF Implementation Notes for Office 2007 SP2). Von Rob Weir und OpenOffice.org-Ninja wurde die ODF-Fähigkeit des SP2 nun grob unter die Lupe genommen: Update on ODF Spreadsheet Interoperability für Tabellenkalkulationen und Microsoft support for OpenDocument ganz kurz für Textverarbeitung.

Alles in allem ist die Interoperabilität zwischen Microsoft’schen ODF-Dateien und denen anderer Software-Hersteller (OpenOffice, KOffice, Google …) noch eher bescheiden. Leider. Aber es ist ein erster Schritt und hoffentlich werden die internen MSO2007-Konverter noch vor dem nächsten Servicepack aktualisiert, wie es bei dem CleverAger-Add-in regelmäßig geschieht. Die Zeit zwischen MSO-Servicepacks ist nämlich sehr lange. Zu lange. (Und es solle ja niemand sagen können, nur MS-eigene Dateiformate erhalten die Interoperabilität und ODF nicht. ;-)

Nun ist nur noch zu hoffen, dass die Ausarbeitung der Spezifikation von ODF 1.2 bald seinen Abschluss findet und in die ISO-Gremien überführt werden kann. Das wäre ein großer Schritt, damit alle ODF-Software-Hersteller (außer Sun Microsystems) von ODF 1.1 auf ODF 1.2 umsteigen können, was der Interoperabilität einen Schub und den Herstellern mehr Möglichkeiten geben würde.

Ich habe heute kurz die ODF-Mailingliste durchstöbert und ein paar interessante Informationen entdeckt.

Derzeit laufen anscheinend die Abschlussarbeiten zu ODF 1.2 im Technischen Komitee für ODF bei der OASIS. In den nächsten Monaten wird der Entwurf der Öffentlichkeit zur Begutachtung präsentiert (die laufenden Arbeiten können jedoch auch schon bei der OASIS eingesehen werden). Danach wird bei der OASIS über ODF 1.2 abgestimmt. Und erst danach wird ODF 1.2 an die ISO weitergeleitet, wo ODF 1.0 bereits als IS 26300 als Norm zertifiziert ist.

Währenddessen wird bis Ende März um Vorschläge gebeten, was in ODF nach Version 1.2 integriert und verbessert werden soll. Die nächste ODF-Version wird „ODF-Next“ genannt. Robert Weir hat dazu in der Mailingliste zu ODF Anfang Februar 2009 einen Textentwurf geschrieben. (Ich habe nicht gesucht, ob diese Ankündigung in der Mailingliste oder sonst wo bereits offiziell verkündet worden ist. Da das Zeitfenster bis 31. März 2009 jedoch sehr kurz ist, gehe ich davon aus, dass das schon geschehen ist.) Die Vorschläge werden gesammelt und am 1. Mai 2009 dem Technischen Komitee vorgestellt.

Weiters hat Robert Weir in der Mailingliste angefragt, ob der Wille und die Zeit dazu besteht, ODF 1.1 bei der ISO einzureichen und die Neuerungen von ODF 1.1 als Ergänzung zu ISO/IEC 26300:2006 zu veröffentlichen.

Auf die Antwort eines Brasilianers, der lieber auf ODF 1.2 warten würde, da der Übersetzungsaufwand so hoch ist und ODF 1.2 ja fast fertig sei, antwortete Dennis Hamilton:

With regard to timing, you said

    "I think that this should be a good idea a few years ago, 
    but with ODF 1.2 almost ready, this decision would impose
    us an unnecessary effort."


I don’t think ODF 1.2 is almost ready as an ISO Standard, and I haven’t done the math on the PAS submission time sequence, but it seems to me that we might be as much as two years away from appearance of an IS for ODF 1.2.Quelle

Also laut seiner Schätzung wird es noch zwei Jahre dauern, bis ODF 1.2 eine ISO-Norm wird.

OpenDocument (ODF) besser

Nachdem Microsoft offiziell die Unterstützung für ODF (OpenDocument) mit dem nächsten Update für Microsoft Office 2007 angekündigt hat, folgt die Aussage des Microsoft-Technikchefs der USA: „ODF has clearly won“ (heise, ubuntuusers). – Techniker denken eben logisch und nicht nur in blinder, propagandistischer Weise wie Verkäufer oder bloße Manager.
Achja, und die Normierung von OOXML ist erstmal auf Eis gelegt, bis Einwände von 4(!) P-Staaten ausgeräumt wurden (z.B. ubuntuusers, heise).

Firefox 3

Firefox 3 ist endlich erscheinen und für die Öffentlichkeit bereit! Laut Aussagen verschiedener Online-Medien ist die Akzeptanz der neuen Browser-Version enorm. Schon innerhalb weniger Tage haben viele Anwender auf die neue Version migriert. Der Browser-Kampf ist auf einer neuen Stufe angelangt. Außerdem hat Mozilla wohl einen neuen Rekord durch den Download-Day aufgestellt: die meisten Downloads eines Software-Programmes innerhalb von 24 Stunden.

Wine 1

Wine 1.0 ist erscheinen. Die runde Versionsnummer hat weniger mit speziellen neuen Funktionen als mit dem runden Datum zu tun: Wine ist nun 15 Jahre alt – und es gibt noch viel zu tun, um möglichst viele Windows-Programme auch unter Linux lauffähig zu machen.

Opera 9.5

Auch Opera hat einen neue Version: 9.50. Es gibt viel Neues und auch viele Verbesserungen hinsichtlich Webstandards. Ich habe es aber noch nicht ausprobiert und kann dazu nicht mehr sagen.

OpenSource-Animationskurzfilm „Big Buck Bunny“

Der Kurzfilm „Big Buck Bunny“ (zu Deutsch: „Großes Dickes Häschen“) ist Anfang Juni veröffentlicht worden. Das ist ein witziger Animationsfilm, der mit der OpenSource-3D-Software Blender erstellt worden ist (ubuntuusers). Sehr empfehlenswert und witzig! Um das Projekt zu unterstützen, kann man die DVD käuflich erwerben. Ansonsten steht der Download in verschiedenen Auflösungen jedem kostenlos zur Verfügung.

Wien im festen Griff Microsofts

Die Stadtgemeinde Wien installiert auf einigen bisher alleinigen Linux-Rechnern ein Dual-Boot-System mit Microsoft Vista: Wien stellt Computer teilweise wieder von Linux auf Windows um, Linux in Wien kämpft mit Kompatibilitätsproblemen, SPÖ prüft Zukunft von Wienux, Kindergarten -Sprachsoftware kann nicht mit Wienux.
Diese Entscheidung basiert allein auf Zeitdruck und auf die verstaubten Wiener Behörden. Würde man die hunderttausenden Euro eher zur Weiterentwicklung von OpenSource-Software, von Wienux (das nur verstaubt und von 1-2(!) Mitarbeitern gepflegt wird – wieso setzt man stattdessen nicht auf Ubuntu mit eigenen Anpassungen?) und der (ClosedSource-)Sprachsoftware investieren, die angeblich nur unter Windows mit dem Internet Explorer läuft und bis Herbst zur Verfügung stehen muss, würde man nicht unsinnigerweise Betriebssysteme kaufen müssen in den Kindergärten, wo bereits erfolgreich Linux genutzt und alltäglich ist. Nächstes Jahr wird die Sprachsoftware auch unter Firefox laufen (d.h. auch unter Linux). Was für ein Pech/Zufall, dass das erst so spät passiert, wo die Sprachsoftware und die dazugehörige Verordnung schon lange auf dem Tisch lag. Bürokratie und Monopolismus. Mehr muss man dazu nicht sagen.

Berlin und besonders München gehen den anderen Weg, der langfristig mehr Unabhängigkeit, mehr regionale Arbeitsplätze und weniger öffentliche Ausgaben bedeutet: Berlin steigt auf Linux um, München setzt auf Linux.

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>

</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:

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.

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.

Nächste Seite »