Als Softwareentwickler tut man sich heute an vielen Stellen schon nicht mehr so schwer, wie noch
vor ein paar Jahren. Vieles ist standardisiert, austauschbar, komponentenorientiert und
plattformübergreifend geworden. Eine der letzten großen Bastionen proprietärer
Softwareentwicklung hat noch lange Zeit Microsoft beigesteuert. Mit den binären Dateiformaten
der wohl bekanntesten Office Suite des Planeten wurde immer wieder gehadert. Ende letzten
Jahres wurde auch dieser Sumpf ausgehoben. Den Nachfolgern von .doc und Co wurde ein x an die
Dateiendung gehangen. Dieses folgt ausnahmsweise keinem Marketingeinfall sondern
versinnbildlicht das zugrunde liegende Dateiformat. Hinter den Kürzeln .docx, .xlsx, usw.
verstecken sich seit Office 2007 xml basierte Dokumente.
Auch wenn es auf den ersten Blick erscheinen mag, als sei XML ein alter Hut: Tatsache ist, dass die
Kombination mit einem defacto Standard wie Office und seinen Artefakten eine sehr schlagkräftige
Kombination ergibt. Sichtbar wird dies erst, wenn man den heimischen Desktop gedanklich verlässt
und sich in die tägliche Arbeit der „Information Worker“ hineinversetzt. Dieser von Microsoft
geprägte Begriff bezeichnet all diejenigen, die bei der Büroarbeit mehrheitlich mit Informationen
zu tun haben und dafür die unterschiedlichsten Werkzeuge verwenden. In Zeiten, in denen die
meisten Unternehmen zentralisierte Anwendungslandschaften betreiben und sich dort
verschiedenste, zumeist webbasierte Lösungen tummeln, besteht der Alltag der „Büromenschen“
zumeist darin sich mit dem Webbrowser durch Anwendungen zu Klicken. Leider ist das komplett
papierlose Büro noch immer keine Wirklichkeit. Daher werden gesammelte und aufbereitete
Informationen anschließend in menschenlesbare und / oder rechtlich geeignete Formate
(Rechnungen, Lieferscheine, Briefe, etc.) gebracht. Das geschieht immer noch recht häufig per
Kopieren und Einfügen. Ein, nicht nur auf den ersten Blick, gewöhnungsbedürftiger Zustand. Dieses
Vorgehen ist nicht nur fehleranfällig, es schafft auch einen zusätzlichen Arbeitsschritt. Viel
einfacher wäre es doch, wenn die zentralen Anwendungen die aufbereiteten Dokumente direkt
fertig abliefern würden. Was sich einfach anhört, war bisher alles andere als das. Der Grund dafür
war nicht zuletzt vor allem das bisher binäre und nicht offengelegte Dateiformat von Microsofts
Office Paket und den enthaltenen Werkzeugen.
Aber natürlich hat sich die Entwicklergemeinde nicht von solchen Schwierigkeiten abschrecken
lassen und auch dafür Lösungen gefunden. Zumindest ansatzweise. Findige Köpfe haben Mittel
und Wege gefunden das geheime Office Format zu entschlüsseln und Frameworks(Java, PHP, etc.)
bereitgestellt, welche einfachste Aufgaben zur Dokumenterstellung übernahmen. Zumindest
unter Unix bzw. Linux Systemen waren aber weder umfangreiche Formatierungen noch
komplexere Aufgaben (bspw. Pivot Grafiken in Excel) bei der okumentengenerierung möglich.
Lediglich auf Windows basierten Systemen können, dank der modularen Bauweise von Office,
mehrere Möglichkeiten genutzt werden. Per COM Zugriff können Word, Excel und Co gestartet
werden oder gar nur einzelne Funktionen aufgerufen werden. Was sich komplex anhört ist im
Programmieralltag noch viel schlimmer. Zumindest, wenn man sich nicht auf einem Microsoft
Betriebssystem bewegen muss. Im einfachsten Fall sind die erhältlichen Frameworks nur langsam
und speicherhungrig. Im schlimmsten Fall können sie genau die eine, benötigte Funktion gar nicht
abbilden. Schlussendlich blieb zumeist nur ein recht einfacher Weg übrig. Der einfache Export von
textbasierten Dateiformaten (bspw csv, o.ä) und ein manueller Import in die gewünschte Office
Anwendung.
Das technische Komitee 45 (TC45) der Ecma International hat diesen leidvollen Zustand im
Dezember 2006 behoben, nachdem Microsoft, auch auf Drängen von Internationalen Regierungen,
das neue XML basierte Dateiformat zur Standardisierung offengelegt hat. Unter dem Namen „Office Open XML“ verbirgt sich ein auf XML basierendes Dateiformat für Büroanwendungspakete.
Als offener Standard soll es den problemlosen Daten- und Dateienaustausch zwischen
Büroanwendungspaketen ermöglichen. Aktuelle Referenzimplementierung ist dabei natürlich
Microsoft Office 2007. Ein Bestandteil des Standards ist dabei die sogenannte WordprocessingML
(auch nur WordML). Die Buchstaben ML stehen dabei für Markup Language. Diese Untermenge
wurde auch schon von Office 2003 verstanden. Auf Grund von Patentansprüchen und der damals
fehlenden Offenlegung war dieser Ansatz aber anscheinend nicht weitgehend genug. Darüber
hinaus wurden die WordML Dokumente als unkomprimierte XML Dateien gespeichert. Was im
Gegensatz zu einem komprimierten Binärformat zu deutlich größeren Dateien geführt hat. Auch
handelte es sich dabei lediglich um eine Ergänzung von Word. Alle anderen Office
Dokumententypen konnten diese nicht nutzen. Erst die weiterentwickelte Version behebt diese
Schwachstellen komplett und öffnet den etablierten Industriestandard für einen übergreifenden
Dokumentenaustausch.
Um in der Anwendungsentwicklung von dem neuen Standard profitieren zu können muss man sich erstmal mit dessen Aufbau beschäftigen. Auf Basis der veröffentlichten Spezifikation ist das Unterfangen allerdings nahezu zum Scheitern verurteil. Sie umfasst mehrere tausend Seiten. Ein einfaches „Hello Word“ kann aber recht simpel erstellt werden. Das soll im Folgenden dann auch passieren. Zuerst zu Fuß und im Anschluss mithilfe von Java. Der neue Office Dateicontainer baut auf einer einfachen, komponentenbasierten und komprimierten ZIP-Datei auf (Package). Jede Datei setzt sich dabei aus einer beliebigen Anzahl von einzelnen Komponenten (Parts) zusammen. Dazu gehören neben XML Dokumenten auch binäre Dateien (bspw. Bilder oder OLE-Objekte). Die XML Dateien haben unterschiedliche Aufgaben. Neben Anwendungsdaten, Metadaten und eigenen Datensätzen werden auch die Beziehungen zwischen den Komponenten in XML Dateien abgebildet. Alle Einzelteile werden im ZIP Format in der entsprechenden Containerdatei (.docx, xlsx, etc.) gespeichert. Beachtenswert ist die Tatsache, dass alle Office-Anwendungen einige Arten von Komponenten gemeinsam verwenden. Dazu gehören beispielsweise Miniaturansichten, Metadaten, Medien und Beziehungen und Dokumenteigenschaften. Viele Komponenten gibt es jedoch nur in dem speziellen Dokumenttyp einer Anwendung. Eine Arbeitsblattkomponente gibt es beispielsweise nur in einem Excel-Dokument. Einen Folienmaster findet man als Komponente nur in einem PowerPoint-Dokument. Wer das alles live und in Farbe sehen möchte, der kann ein von Office 2007 generiertes Dokument einfach umbenennen. Statt .docx einfach in .zip. Mit dem Zipprogramm der Wahl einfach auspacken und sich die Strukturen auf der Festplatte selber anschauen. Allerdings sollte man keinen all zu großen Schock bekommen. Die von den Office Programmen generierten Dokumente weisen schon eine recht komplexe Struktur aus.
Am besten startet man daher vielleicht doch direkt selber mit einem Beispiel. Alles, was man dafür benötigt ist ein Editor der Wahl (gerne auch ein XML Editor) und einen Rechner. Zuerst wird ein leeres Verzeichnis beliebigen Namens erstellt. Gerne c:\heisewordbeispiel\. Hier hinein gehört die erste XML Datei mit dem zugegebenermaßen komischen Namen [Content_Types].xml. Sie sollte den folgenden Inhalt haben:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Types xmlns="http://schemas.openxmlformats.org/
package/2006/content-
types">
<Default Extension="rels" ContentType="application/vnd.openxmlformats-
package.relationships+xml"/>
<Default Extension="xml" ContentType="application/vnd.openxmlformats-
officedocument.wordprocessingml.document.main+xml"/>
<Default Extension="gif" ContentType="image/gif"/>
</Types>
Neben der Datei muss in diesem Ordner noch ein neues leeres Verzeichnis mit dem Namen _rels
entstehen. Für dieses Beispiel soll noch das iX Logo in das Word Dokument. Mit dem Namen
ix_logo.gif wandert es ebenfalls in den zuerst angelegten Beispielordner. Jetzt fehlt noch das
eigentlich Dokument mit den Inhalten. Dafür muss erstmal eine leere Datei document.xml in den
Beispielordner. Sind die Einzelteile an ihrem Platz, dann fehlen noch die Beziehungen zwischen
allen. Dafür wird zuerst die Datei .rels im noch leeren Unterzeichnis _rels erstellt. Auch wenn sie
einen ungewöhnlichen Namen hat handelt es sich wiederum um eine XML Datei. Unter Windows
ist das allerdings nicht so einfach. Ein simples umbenennen eines neuen Dokumentes mit dem
Explorer funktioniert nicht. Entweder kopiert man sich eine vorhandene Datei mit dem Namen
oder man behilft sich mit einem Trick im guten alten Dos-Fenster (echo ““ > .rels). Dieser Befehlt
erstellt eine leere Datei mit dem benötigten Namen. Auch wenn das Gesamtkonstrukt Office
Dokument eigentlich nur aus Beziehungen zwischen Dateien besteht und es keine
vorgeschriebene Verzeichnisstruktur gibt, so ist das Vorhandensein dieser Datei obligatorisch. Sie
spezifiziert den Startpunkt für das fertige Worddokument. In diesem Fall hat sie folgenden Inhalt:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Relationships
xmlns="http://schemas.openxmlformats.org/
package/2006/relationships">
<Relationship Id="rId1"
Type="http://schemas.openxmlformats.org/
officeDocument/2006/relations
hips/officeDocument"
Target="document.xml"/>
</Relationships>
Damit das Bild in das Dokument eingebunden werden kann, muss noch eine weitere Beziehung zwischen dokument.xml und dem Bild hergestellt werden. Dies passiert in der Datei document.xml.rels. Auch sie gehört in das Unterverzeichnis _rels und hat folgenden Inhalt:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Relationships
xmlns="http://schemas.openxmlformats.org/
package/2006/relationships">
<Relationship Id="rId4"
Type="http://schemas.openxmlformats.org/
officeDocument/2006/relations
hips/image"
Target="ix_logo.gif"/>
</Relationships>
Nun sind alle Beziehungen geknüpft und wir können uns dem eigentlichen Inhalt widmen. Dazu
muss der folgende Inhalt in die Datei document.xml:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<w:wordDocument
xmlns:r="http://schemas.openxmlformats.org/
officeDocument/2006/relationship
s"
xmlns:v="urn:schemas-microsoft-com:vml"
xmlns:w="http://schemas.openxmlformats.org/
wordprocessingml/2006/main">
<w:body>
<w:p>
<w:r>
<w:t>Hello Word! from iX</w:t>
</w:r>
</w:p>
<w:p>
<w:r>
<w:pict>
<v:shape
id="_x0000_i1025"
type="#_x0000_t75"
style="width:137; height:85">
<v:imagedata r:id="rId4"/>
</v:shape>
</w:pict>
</w:r>
</w:p>
</w:body>
</w:wordDocument>
Jetzt sollte alles an seinem Platz sein. Ein Verzeichnis mit drei Dateien, einem Unterverzeichnis und
darin nochmal zwei weitere Dateien. Zeit, alles zu einem Word Dokument zusammen zu bauen.
Alles was man nun noch benötigt ist ein ZIP Programm. Dabei ist lediglich darauf zu achten, dass in
der ZIP Datei kein weiteres Unterverzeichnis entsteht. Sonst kann Word die Datei nicht öffnen. Das
klappt dann recht einfach. Die ZIP Datei wird in .docx umbenannt und geht es auch schon los. Ein
Doppelklick öffnet Word und dieses zeigt das „Hallo Word“ an. Wer kein aktuelles Office 2007 zur
Hand hat, der kann auch einen Konverter für 2000 bzw 2003 installieren. Damit lassen sich die
neuen Formate zumindest noch in Office Versionen 2000 und 2003 öffnen. Ältere Versionen
werden leider nicht mehr Unterstützt.
Probleme kann es bei der manuellen Erstellung im Übrigen genug geben. Neben ungültigen
Zeichen in den XML Dateien ist das Format sehr sensibel bzgl. Tippfehlern. Word ist als
Endnutzerwerkzeug leider auch nicht dafür ausgelegt, entsprechend vielsagende Fehlermeldungen
zu erzeugen. Ein guter Ansatz ist also immer, die XML Dateien auf ihre Gültigkeit zu prüfen.
Syntaktisch richtige Dokumente sind allerdings für Office noch immer kein Garant zur korrekten
Anzeige bzw. erfolgreichen Interpretation. Hier bleibt oft nur Versuch und Fehler. Nur die
Microsoft Entwicklungsumgebung Visual Studio ist hier ein wenig komfortabler ausgestattet. Hat
man allerdings dann ein fertiges Dokument welches man sich etwas genauer anschauen mag, dann
kann der Package Explorer sehr hilfreich sein. Das kleine Werkzeug hilft bei der Navigation durch
das Dateichaos in den komprimierten Zips. Das hier vorgestellte Beispiel deckt natürlich nur einen
sehr kleinen Teil der Spezifikation ab. Neben der kompletten Formatierung kann man auch
beliebige Daten in ein Word Dokument packen. Liegen diese bereits im XML Format vor, muss
diese einfach als Quelldatei mit in dem Verzeichnis landen und via Beziehung referenziert werden.
Hat man einmal das Grundgerüst von XML und den Beziehungen verstanden, dann ist klar, dass dieses neue Dokumentenformat grundsätzlich einfach zu generieren ist. Dank dem offenen XML Format kann das heutzutage auch mit fast jeder Programmiersprache erfolgen. Ebenfalls schön ist, dass sich XML doch sehr weit Verbreitet hat und von den Entwicklern angenommen wird. Aber auch hier ist es kein Wunder, dass Microsoft nicht nur die Referenzimplementierung mit Office liefert, sondern auch als einziger Anbieter schon eine verwendbare API für seine Entwickler auf Basis von .NET bereithält. Sie kapselt das lästige Arbeiten mit Dateien, XML-Schema und ähnlich nervigem und ermöglicht einen Zugriff auf Office Dokumente und ihre Teile auf Objektebene. Man muss sich also nicht über Gebühr mit XML rumschlagen. Für den Rest der Programmiersprachen sieht es noch nicht so gut aus. Weder bei bekannten OpenSource Lieferanten noch im Produktumfeld findet man halbwegs stabile Lösungen. Aber das ändert sich sicherlich schnell. Erste Projekte sind initiiert und auf dem Weg zu erstem Produktiven Quellcode. Will man dennoch aktuell schon mit Java aktuell loslegen, dann kann man das mit überschaubarem Aufwand tun. Einzig mit XML Verarbeitung sollte man sich schon ein wenig auskennen. Die kompletten Schemata der verwendeten XML Namespaces stellt Microsoft auch zur Verfügung. Und eine Zipdatei kann Java auch schon länger generieren (java.util.zip.* Package). Für die ersten Schritte ist das sicherlich nicht der Traum eines Entwicklers, sich mit FileOutputStream und ZipFileEntry herumzuschlagen aber es geht. Und es ist auf alle Fälle stabiler und einfacher zu implementieren, als wenn man auf Apache POI oder ähnliches zurückgreifen muss. Neben der einfachen Erzeugung bieten sich auch noch weitere Dinge an. So kann beispielsweise ein Datenimport zukünftig per Excel Datei als Quelle ausgeführt werden. Oder Webcontentmanagementsysteme werden mit Word Dateien gefüttert. Ebenfalls denkbar ist eine Komplette Publishing Strecke auf deren Weg ein vom Autor erstelltes Word Dokument direkt in HTML und weiter in PDF verwandelt wird. Dabei könnte mit dem Office Open XML Format das Wordformat immer die führende Datenquelle bleiben. Wem das noch immer zu wenig Dynamik bei Word, Excel und Co ist, der kann sich auch aus anderem Blickwinkel dem neuen Dateiformat nähern. Neben der einfachen Erstellung der eigentlichen Dokumente per XML, können mit der neuen Spezifikation auch XML-Daten in die Dokumente eingebettet werden. Dabei können diese Daten in nahezu beliebigem XML Format vorliegen. Per Ressource Verknüpfung können diese, auch Custom XML Parts genannten Teile der Spezifikation, in Word, Excel oder Powerpoint Dateien enthalten sein. Angezeigt oder Eingebunden werden die enthaltenen Daten dann per SDT (StructuredDocumentTag). Ein SDT ist die XML Repräsentation eines Content Controls. Dieser muss dann per Custom XML Mapping an einen Custom XML Part gebunden sein. Auf einzelne Felder eines XML Dokuments wird dabei per XPath Ausdruck zugegriffen. Für die Anzeige eines Titels aus folgenden XML:
<magazine>
<artikel>
<titel>Word ML</title>
[...]
</article>
</magazin>
könnte dies dann im Word Dokument ungefähr folgendermaßen aussehen:
<w:sdt>
<w:sdtPr>
<w:dataBinding w:xpath="/magazine/artikel/titel" />
</w:sdtPr>
[...]
</w:sdt>
Dabei können mithilfe eines SDT verschiedene Typen von Eingabefeldern abgebildet werden. Neben einem Rich-Text Feld gibt es noch, Datums- und Bilder-Felder, Drop-Down- und Kombo- Boxen. Wem die manuellen Aufbereitung solch doch komplexerer Dokumente zu viel ist, der kann sich auch des Content Control Toolkits (siehe Kasten Links) bedienen. Es unterstützt das Mapping von Custom XML Parts an die Content Controls. Wer all dies ohne Hilfe von Open Source Software versucht per Hand in XML abzubilden wird schnell scheitern. Die von Word, Excel und Co. generierten Fehlermeldungen bei unvollständigem oder fehlerhaftem XML sind einfach zu wenig aussagekräftig, als das sie den ambitionierten Entwickler bei der Fehlersuche deutlich unterstützen würden. Bis auf die Angebe von Ort, Zeile und Zeichen gibt der Klick auf „Details“ bei einer entsprechenden Fehlermeldung nicht viel her. Daher führt bei der manuellen Generierung zurzeit noch kein Weg an Package Explorer und Content Control Toolkit vorbei.
Auch wenn alles so einfach ist, bleibt ein Wehrmutstropfen. Die Mitbewerber sind nach wie vor
nicht Glücklich mit dem neuen Industriestandard. Neben der Tatsache, dass Microsoft alle Office
Versionen vor 2000 damit komplett abhängt sorgt vor allem die Komplexität der Spezifikation für
Unmut. Statt auf bereits vorhandene Spezifikationen (MathML, SVG) zu setzten, hat Microsoft sich
entschlossen alles neu zu machen. Nur mit viel Mühe und Zeit wird ein Dritthersteller wohl in der
Lage sein, den kompletten Umfang in den eigenen Produkten abzubilden. Schaut man sich weiter
um unter den Argumenten der Kritiker, dann bleibt vor allem ein dickes Fragezeichen zurück.
Dieses Fragezeichen heißt OpenDocument. Dieses, unter der ISO/IEC norm 26300:2006 spezifizierte
Dokumentenformat von OASIS gibt es bereits seit Mai 2005. Basis hierfür ist das als Opensource
erhältliche Office Paket OpenOffice. Das grundlegende Konzept ist dabei erstaunlich gleich. Auch
bei OpenDocument werden Zipdateien verwendet um XML Fragmente zu einem Dokument
zusammenzufassen. Lediglich Spezifikation und Dateiendungen unterscheiden sich. Die Liste der
OpenDocument Unterstützer ist auf alle Fälle aktuell viel länger als die Liste derer, die sich für
Office Open XML ausgesprochen haben. Auch wenn sich die Argumente für ein offenes
Dokumentenformat komplett gleichen: Neben der Notwendigkeit zur Erfüllung von gesetzlichen
Anforderungen an die Revisionssicherheit sind das vor allem die Sorgen um eine Abhängigkeit von
einem speziellen Hersteller. Darüber hinaus wird der Wunsch nach einem einfach
auszutauschenden Format vorgebracht, was möglichst viele Anwendungen lesen können.
Pluspunkt auf der Seite von Microsoft bleibt die Tatsache, dass die Office Suite und daraus vor
allem Word, Excel und Powerpoint mit Abstand verbreiteter sind als alle OpenSource Office Pakete
zusammen. Eine Entscheidung für die eine oder die andere Richtung für die Dokumentenerstellung
in der Zukunft ist noch lange nicht gefallen.
