Erstellen und Verarbeiten von Office-Dokumenten mit verschiedenen Programmen

Viel ist über das OASIS Open Document Format geschrieben worden. Eine Menge davon sind Mythen oder einfach schlichte Fehlinformationen. Vor allem Microsoft hält sich nicht zurück auf vermeintliche Beschränkungen und Unzulänglichkeiten des Formats hinzuweisen. Bei genauerer Betrachtung verwundert dieses Verhalten nicht, denn Microsoft setzt auf seine eigene Entwicklung, das Office-Open-XML-Format. Erwächst zwischen den Formaten eine Konfrontation vergleichbar mit dem Browser-Krieg oder sind wir etwa schon inmitten solch einer Konfrontation?

Von Diese E-Mail Adresse ist gegen Spam Bots geschützt, Sie müssen Javascript aktivieren, damit Sie es sehen können

1. Einführung

Um die Frage zu klären, ob uns eine Auseinandersetzung zwischen den Office-Formaten erwartet, müssen wir uns zuerst einmal mit den Motiven befassen. Denn ohne strategische Interessen lohnt sich selten ein Konflikt. Also begeben wir uns erst einmal auf die Suche nach dem generellen Sinn neuer Office-Formate. Jahrelang haben wir schließlich unsere Texte in den herkömmlichen, nicht-öffentlich dokumentierten Formaten abgespeichert. Was hat sich seitdem geändert?

Die Antwort auf diese Frage berührt ein Phänomen, das zurzeit die IT-Welt beschäftigt: Systeme werden nicht mehr isoliert betrieben, sondern hochgradig vernetzt. Diese Vernetzung von unterschiedlichen Systemen hat sich heimlich, still und leise zu einer Schlüsselfunktion für moderne IT-Infrastrukturen entwickelt.

Die grundsätzliche Idee hinter der Vernetzung von verschiedenen Anwendungsprogrammen ist dabei recht einfach und keineswegs neu. Im Prinzip stellt dieser Schritt eine konsequente Weiterentwicklung der Idee von vernetzten Rechnern dar. Eine Idee, die spätestens mit der Realisierung des Internets einen weltweiten Siegeszug angetreten hat.

Es ist damit zu rechnen, dass in Zukunft Programme, die sich nicht in vernetzte IT-Strukturen integrieren lassen, Nachteile in der kommerziellen Nutzung haben werden. Hier geht es somit um handfeste wirtschaftliche Interessen.

Um den Sinn und die Bedeutung dieser Vernetzung zu verdeutlichen, betrachten wir im folgenden Absatz ein Einsatzszenario aus dem Bereich E-Government. Der Bereich E-Government eignet sich hervorragend zum Illustrieren der Auswirkungen einer solchen Vernetzung, da in der Regel ein Zwang zur Nutzung von E-Government-Diensten besteht, wie das Beispiel elektronische Steuererklärung zeigt. Wenn dann solch ein Dienst nur mit einem einzigen Programm nutzbar ist, wird aus dem Zwang zur Nutzung des Dienstes schnell ein Zwang zur Nutzung einer bestimmten Software. Solch eine starke Abhängigkeit muss verhindert werden.

Ziel des Szenarios ist es, Antragsformulare mit Hilfe von elektronischen Prozessen abzubilden. Es muss also eine Ende-zu-Ende-Beziehung zwischen dem Anwender, in der Regel dem Bürger, und dem Anbieter der Dienstleistung hergestellt werden. Abbildung 1 zeigt den schematischen Aufbau solch einer Ende-zu-Ende-Beziehung, bei der der Bürger mit seiner Office-Anwendung das eine Ende und eine Behörde mit ihrer IT-Struktur das andere Ende darstellt.

Bislang ist dieses Beispiel jedoch noch nicht sehr spannend: statische Formulare anbieten und ausfüllen ist heutzutage kaum noch eine Herausforderung. Interessant wird dieses Szenario erst dann, wenn die Formulare für jeden Kunden individualisiert werden sollen. Um solche individuell auf jeden Kunden zugeschnittene Formulare anzubieten, müssen die beteiligten Komponenten auf der Anbieterseite inhaltlich eng zusammenarbeiten. Komponenten wie Office-Programme, Formular-Generatoren und Fachanwendungen stehen nun vor der Aufgabe, ihre Daten untereinander so auszutauschen, dass am Ende das gewünschte individuelle Formular herauskommt. Somit ergibt sich für den Anbieter folgende Situation:

• Textbausteine werden in Office-Programmen erstellt.
• Formularbausteine werden mit Formular-Generatoren erstellt.
• Persönliche Daten des Kunden sind in den Fachanwendungen hinterlegt.

Ein individuelles Office-Dokument für einen Nutzer wird nun aus den vorhandenen Textbausteinen, Formularbausteinen sowie den vorhandenen Daten des Kunden hergestellt.

Durchgespielt sieht das Szenario folgendermaßen aus: der Bürger bekommt über das Internet ein individuelles Formular ohne unnötigen Ballast, das er mit seiner Office-Suite auffüllen kann. Das fertig ausgefüllte Formular landet via Internet wieder beim Anbieter. Danach werden die Inhalte automatisiert in das jeweilige Fachverfahren eingespeist und bearbeitet.

Dieses Szenario bedingt, dass viele unterschiedliche Komponenten Daten austauschen müssen. Die Fähigkeit zur Zusammenarbeit von verschiedenen Programmen bezeichnet man auch als Interoperabilität. Dateiformate haben somit nicht mehr die alleinige Aufgabe, Daten persistent zu speichern, sondern dienen auch als Informationsträger zwischen verschiedenen Programmen. Dies hat zur Folge, dass Computerprogramme der Zukunft solche Dokumentenformate unterstützen müssen, die die Interoperabilität unterstützen. Ohne diese Fähigkeit wird eine Software nicht im Konzert der zusammenarbeitenden Komponenten mitspielen können.

Das Problem, das nun gelöst werden muss, ist folgendes: Wie überwinden wir das babylonische Sprachgewirr im Dschungel der Computerprogramme oder anders formuliert, wie schaffen wir eine Lingua Franca für Computeranwendungen?

2. XML - Lösung des Problems?

Das Problem der Interoperabilität von Computerprogrammen zerfällt bei genauerer Betrachtung in zwei verschiedene Ebenen: die technische Interoperabilität und die semantische Interoperabilität.

Glaubt man den Marketingaussagen einschlägiger Softwarehersteller, so besteht die Antwort auf alle Fragen der Interoperabilität aus drei groß geschriebenen Buchstaben - XML. Leider ist dies etwas idealistisch betrachtetet, was ein genauerer Blick auf XML belegt.

XML ist eine generelle Technologie zur Erzeugung von Sprachen bzw. Dokumentenformaten (diese Sprachen werden XML-Anwendungen genannt). Genau genommen hilft XML vor allem bei der Überwindung der technischen Interoperabilität.

Eine vollständige Interoperabilität benötigt allerdings neben der technischen Ebene zusätzlich die semantische Ebene. Diese semantische Ebene sorgt dafür, dass die übertragenen Informationen auch überall gleich verstanden werden. Sprechen wir die gleiche Sprache, so belegen wir gesprochene Wörter und Sätze mit einer gemeinsamen Bedeutung. Ohne diese gemeinsame Basis ist ein gesicherter Informationsaustausch nicht möglich. XML lässt uns jedoch bei der Überwindung der semantischen Interoperabilität weitgehend allein. Abbildung 2 zeigt, welchen Beitrag XML für die Interoperabilität leisten kann. Bei der Zusicherung der semantischen Interoperabilität sind die Programmierer jeder Anwendung gefordert, beispielsweise in dem sie mit Hilfe von Interoperabilitäts-Tests die Semantik in ihrer Software abgleichen. Ein weiterer Vorteil von XML sind die zahlreichen Komponenten und Werkzeuge, auf die zurückgegriffen werden kann. So existiert eine komplette Werkzeugkette für die technische Ebene.

Abbildung 2: Einordnung von XML zu den Interoperabilitätsebenen

Was bringt uns nun XML mit Blick aus das Gesamtproblem der Interoperabilität? XML stellt eine wichtige Technologie zum Vernetzen von unterschiedlichen Programmen dar. Jedoch reicht XML alleine nicht aus, sondern stellt lediglich den ersten Schritt dar. Mit dieser soliden Basis kann nun der nächste Schritt gewagt werden - das Erzeugen und Standardisieren von XML-Anwendungen, mit dem Ziel, Interoperabilität auf der semantischen Ebene herzustellen.

3. Das Open Document Format

Um die Geschichte des Open Document Formats (ODF) zu erzählen, müssen wir in das Jahr 1984 zurückgehen. In diesem Jahr wurde in Hamburg die Firma Star Division gegründet, die ein Produkt namens StarOffice entwickelte. Nachdem Star Division über 25 Millionen Exemplare ihrer Office-Suite verkauft hatte, wurde die Firma von SUN gekauft. Jedoch gelang es dem Gründer von Star Division, SUN davon zu überzeugen, dass ab dem Zeitpunkt der Übernahme die Weiterentwicklung von StarOffice unter einer freien Lizenz betrieben werden sollte. Dieser geschickte Schachzug kennzeichnete die Geburtsstunde von OpenOffice.

Eine der Neuheiten von OpenOffice war die Verwendung von XML zum Speichern und zum Laden der OpenOffice-Dokumente. Mit Erscheinen von OpenOffice 1.0 am 1. Mai 2002 wurde auch eine Dokumentation des von SUN erstellten Open Office XML File Formats veröffentlicht. Jedoch nutzten zu dieser Zeit ausschließlich OpenOffice und StarOffice (die proprietäre Version von OpenOffice) das Format, da es speziell auf die Fähigkeiten von OpenOffice zugeschnitten war.

Kurz nach dem Erscheinen von OpenOffice 1.0 beauftragte das Bundesamt für die Sicherheit in der Informationstechnik eine Studie, um der Frage nachzugehen, welche Fähigkeiten ein offenes Format für Office-Dokumente benötigt. Diese Studie stellte einen wichtigen Meilenstein auf dem Weg zum OASIS Open Document Format (ODF) dar, denn im Rahmen dieser Studie trafen sich Entwickler von verschiedenen Office-Suiten auf dem LinuxTag 2002, um über ein gemeinsames XML-basierendes Dokumentenformat zu diskutieren. Im November 2002 war es dann soweit, SUN hatte eine Arbeitsgruppe bei der auf Standardisierung von XML-Anwendungen spezialisierten Organisation OASIS eingerichtet und dies offiziell mit einer E-Mail angekündigt.

Drei Jahre später, am 1. Mai 2005, erblickte dann schließlich das OASIS Open Document Format das Licht der Welt. Dieser Standard war eine konsequente Weiterentwicklung des Open Office File Formats. Jedoch war es um einiges umfangreicher, so dass es auch die Anforderungen von anderen Office-Suiten abdecken konnte. Eine weitere Änderung war nicht inhaltlich, sondern strategisch: ODF war von Anfang an ein offener Standard, an dessen Entstehen nicht nur Vertreter von SUN, sondern auch Mitarbeiter von IBM und Entwickler von KOffice beitrugen.

Ein offener Standard soll möglichst breit eingesetzt werden. Dies wird erreicht, in dem die Barrieren zum Implementieren möglichst gering sind. Außerdem versucht ein offener Standard, einen größtmöglichen Konsens aller Beteiligten anzustreben.

Ein Standard ist dann ein offener Standard, wenn er von jeder Software, egal unter welcher Lizenz sie vertrieben wird, implementiert werden darf, wenn er ausreichend gut dokumentiert ist und wenn jeder an der Erstellung des Standards mitarbeiten kann.

Im Gegensatz zum offenen steht ein proprietärer Standard. Das Wort proprietär kommt aus dem Lateinischen und bedeutet soviel wie Besitz. Ein proprietärer Standard ist ein Standard, der im Besitz einer oder mehrerer Firmen bzw. Organisationen ist. Dies bedeutet, dass die Besitzer entscheiden können, welche Programme den Standard nutzen können.

Eine weitere Besonderheit von Open Document Format ist die konsequente Wiederverwendung von bereits etablierten Standards. So basiert ODF auf XML und verwendet unter anderem die W3C-Standards SVG und XForms sowie den Standard für Metadaten Dublin Core. Abbildung 3 zeigt eine Übersicht der in ODF verwendeten Standards und ihre zeitliche Einordnung.

Abbildung 3: Zeitlicher Verlauf der ODF-Entwicklung

Die konsequente Wiederverwendung von existierenden und etablierten Standards stellt einen der größten Vorteile von OASIS Open Document Format dar. Denn durch die Wiederverwendung beschleunigte sich nicht nur die Entwicklung des Standards selbst, sondern es stellt auch eine große Erleichterung für Programmierer dar, die den Standard in eigene Software integrieren möchten. Denn diese Programmierer können in der Regel ebenfalls auf schon existierende Software-Komponenten und -Werkzeuge zurückgreifen.

Aufgrund dieser einfachen Integrationsmöglichkeit verwundert es nicht, dass ODF von einer ganzen Reihe von Programmen bereits verarbeitet werden kann. So kann man unter anderem mit OpenOffice, KOffice, Abiword, Textmaker und IBM Workplaceshell Dokumente in ODF laden und speichern. Laut Wikipedia unterstützen zur Zeit über 25 Programme das OASIS Open Document Format, wobei die Nutzung nicht auf Office-Suiten beschränkt ist. Auch Contentmanagement-Programme wie beispielsweise Typo3 können ODF-Dokumente lesen und verarbeiten.

Einen Wermutstropfen in der Unterstützung von Open Document Format muss jedoch erwähnt werden. Mit Microsoft Office ist es also nicht möglich, ODF-Dokumente zu laden oder zu speichern. Den genauen Grund, warum Microsoft keine Unterstützung von ODF in das eigene Office einbaut, kennen wohl nur die Firmenstrategen aus Redmond. Jedoch ist zu vermuten, dass Microsoft befürchtet, bei zu guter Interoperabilität zwischen OpenOffice und MS Office Marktanteile zu verlieren.

Offiziell ist Microsoft der Ansicht, dass ODF nicht ausreiche, um alle Funktionen von MS Office vollständig abzubilden. Um dennoch auf den XML-Zug aufzuspringen, schickten sie kurzerhand eine eigene XML-Anwendung ins Rennen. Diese von Microsoft entwickelte XML-Anwendung Office Open XML hat mit ODF außer der Verwendung von XML nichts gemeinsam. Interessant ist jedoch, das bislang alle Argumente von Microsoft, die belegen sollten, warum ODF nicht für MS Office geeignet ist, widerlegt werden konnten. Einen Vergleich der beiden XML-Anwendungen ist in Tabelle 1 aufgeführt.

4. Koexistenz ODF und Microsoft

Es sieht also ganz so aus, als müssten wir mit zwei konkurrierenden Formaten leben. Aber ging es bei XML-basierten Dokumentenformaten nicht darum Interoperabilität zu erreichen? Es würde ja ausreichen, wenn MS Office zusätzlich zu Office Open XML auch ODF lesen und schreiben könnte. Wie könnte solch eine Integration aussehen, die die Interoperabilität stark verbessern würde? Es gibt mindestens zwei Wege, wie diese Integration erreicht werden könnte.

Zum einen könnte Microsoft diese Funktionalität selbst hinzufügen. Hierzu muss der Leidensdruck für Microsoft allerdings hoch genug sein. Unmöglich ist dies jedoch nicht, denn der öffentliche Druck steigt stetig an. Den Anfang dieses Drucks bereitete die IDABC der Europäischen Union. Der IDABC ist es unter anderem zu verdanken, dass SUN das Open Document Format bei der ISO als Norm angemeldet hat. Diese Normierung wurde gerade abgeschlossen. Der fertige ISO-Standard wird wohl stark zur Verbreitung von ODF beitragen.

Die Ankündigungen des US-Bundesstaates Massachusetts, der spanischen Regionalregierung der Extremadura, der Regierung von Dänemark sowie der Regierung von Belgien in Zukunft ihre offiziellen Dokumente nur noch in PDF und ODF anzubieten, haben zusätzlichen Druck auf Microsoft ausgeübt. Ebenfalls wichtig zum Aufrechterhalten des öffentlichen Drucks war die Gründung der ODF Alliance.

Die Open Document Alliance ist ein weltweiter Interessenverband mit dem Ziel der Förderung von ODF. Mittlerweile haben sich weltweit 280 Organisationen unter diesem gemeinsamen Marketing- und Lobby-Dach zusammengefunden. Darunter sind internationale Firmen wie Google, IBM, SUN oder EDS, aber auch Städte wie Bristol oder Wien.

Dieser stetige Druck hat bereits zu ersten Erfolgen geführt. So unterstützt Microsoft offiziell ein Projekt, um ODF-Dokumente in MS Office zu importieren. Sollte Microsoft in dieser Sache wieder an Fahrt verlieren, so kann zusätzlich ein anderer Weg beschritten werden. Jeder Programmierer mit genügend Zeit und ausreichenden Fähigkeiten in MS-Office-Programmierung kann eine ODF-Unterstützung in MS Office mit Hilfe der APIs von MS Office hinzufügen. In der Zwischenzeit hat sich eine von Microsoft unabhängige Initiative gebildet, die genau die Integration von ODF in MS Office zum Ziel hat. Leider sind die Ergebnisse dieser Initiative noch nicht öffentlich verfügbar.

5. Ausblick

Sollen Daten wie Texte, Tabellen oder sonstige Office-Dokumente zwischen verschiedenen Anwendungen ausgetauscht werden, so kann Open Document Format dazu einen wichtigen Beitrag leisten. ODF ist gut dokumentiert, darf in jeder Software genutzt werden, und jedem steht die Mitarbeit an der Fortentwicklung in der OASIS-Arbeitsgruppe offen. Diese Eigenschaften haben bislang für eine breite Akzeptanz gesorgt.

Das Szenario aus dem ersten Teil dieses Artikels ließe sich schon heute mit vorhandenen Softwarekomponenten und Nutzung von ODF realisieren. Länder wie Belgien oder Dänemark zeigen, dass dieses Szenario bald schon Realität werden kann.

6. Links und Literatur

7. Über den Autor

Oliver Zendel beschäftigt sich seit über zehn Jahren mit den Themen freie Software und offene Standards. Er ist Gründungsmitglied des LinuxTag e.V. und seit Bestehen des Vereins Mitglied des Vorstandes.

Seinen Abschluss als Diplom-Informatiker machte er an der Technischen Universität in Kaiserslautern.