Das Microsoft Open XML Format (Teil 1)

Eine der Gründe für die Öffnung des Office-Dokumentformats war der recht profane Umstand, dass Ausschreibungen im öffentlichen Bereich voraussetzen, dass ein offenes Dokumentformat verwendet wird. Zwar gab es mit dem Open Document Format (ODF) bereits ein solches Format, das offen und unabhängig ist (wenngleich getrieben durch die unermüdlichen Bemühungen von IBM), doch steckte dieses zur damaligen Zeit noch ein wenig in den Kinderschuhen und kam alleine bezüglich seines Funktionsumfangs für Microsoft nicht in Frage. Das Microsoft Office-Paket verlangte komplexere Strukturen, um einerseits sämtliche Funktionalitäten im Dokument unterbringen zu können und andererseits kompatibel zu älteren Office-Formaten zu sein. Ein mit Office 2003 oder Office XP erstelltes und komplett formatiertes Dokument soll nach dem Abspeichern in Word 2007 noch genauso aussehen wie vorher. Eine Neuentwicklung musste her.Ende 2006 veröffentlichte Microsoft die unter Mithilfe vieler Vertreter aus Industrie und öffentlichen Einrichtungen (Toshiba, Apple, British Library usw.) entstandene Spezifikation für Open XML. Fast gleichzeitig kam Office 2007 auf den Markt und implementierte Open XML in Excel, PowerPoint und Word. Was für Office einen großen Sprung bedeutet, dürften die meisten Anwender nicht einmal bemerkt haben.Ein Blick unter die HaubeEin Blick in das Innere einer Docx-, Pptx- oder Xlsx-Datei (dazu muss lediglich die Erweiterung in .Zip geändert werden) macht deutlich, dass ein Office 2007-Dokument intern aus einer einfachen Ordnerstruktur besteht. Es gibt Unterordner und Dateien, von denen die meisten die Erweiterung .Xml tragen. Der allgemeine Aufbau eines solchen Packets wird durch die Open Packaging Convention (OPC) beschrieben. Sie sorgt dafür, dass sich die Dokumentformate für Excel, Word und PowerPoint nur geringfügig unterscheiden. Die OPC besagt im Wesentlichen, dass eine Open XML-Datei ein Zip-komprimierter Container ist, der sog. Document Partsenthält. Diese Parts sind der besseren Übersichtlichkeit halber hierarchisch angeordnet und enthalten die ,,logische Bestandteile" des Dokuments wie z.B. die Dokumenteigenschaften, eingebettete Bilder, Hyperlinks und eventuell auch eine Liste der vorhandenen Formatvorlagen. Auch der Dokumentinhalt selber wird durch ein solches Part repräsentiert. Die einzelnen Parts werden über Beziehungen (Relationships) miteinander verbunden, die ebenfalls als XML-Dateien vorliegen (Abbildung 1). Abbildung 1: Die Document-Package-Part-Struktur Die meisten Parts liegen XML-Format vor, einige, wie Bilder, Videos und Makros, können aber auch im Binärformat vorliegen (dass das Dokumentformat OpenXML ist bedeutet daher nicht, dass alles textbasierend gespeichert wird) Die Bedeutung einer Datei als Teil des Zip-Containers wird über sog. Content Types beschrieben. Wie MIME-Types übernehmen sie die Aufgabe, der Anwendung ,,mitzuteilen", was diese mit einer Datei anfangen soll. Die physische Struktur ist lediglich ein äußerer Rahmen, den Microsoft vorgegeben hat, um die Lesbarkeit und Verständlichkeit zu verbessern. Da die einzelnen Parts über Beziehungen verbunden sind, spielt die genaue Struktur keine Rolle, sofern die Beziehungen die Struktur eindeutig beschreiben. Eine Beziehung besteht aus einer Id (logische Adresse), einem Referenzschema (Type) und dem Ziel (Target, physische Adresse), dem Ort, wo die Komponente innerhalb des Containers zu finden ist. Die Pfade sind stets relativ, gehen also immer von der gerade aktiven Ebene aus:Id="rId3" Type="http://schemas.../metadata/core-properties" Target="docProps/core.xml"/>Der Dokumentinhalt, um den es in der Regel geht, befindet sich im sog. MainDocumentPart, bei Word ist es die Datei Document.xml. Sie enthält den Inhalt des Word-Dokuments im XML-Vokabular WordProcessingML (das im zweiten Teil der Serie etwas ausführlicher vorgestellt wird).Programmatischer ZugriffDer inzwischen von der ECMA als Nummer 376 [1] bzw. der ISO als Nummer 29500 [2] akzeptierte Standard stellt im Vergleich zum proprietären Binärformat eine wesentliche Erleichterung für Softwareentwickler dar. Die für den direkten Zugriff auf die Dokumente erforderlichen APIs gibt es für allen relevanten OS-Welten, die mit Zip-Archiven bzw. XML umgehen können und XPath für den Zugriff auf einzelne Knoten (und damit Dokumentelemente) ist inzwischen auch vielen Entwicklern vertraut. Besonders komfortabel haben es natürlich .NET-Entwickler. Seit Version 3.0 gibt es im Framework den Namespace System.IO.Packaging, der Klassen enthält, die einen Zugriff auf Dokumentdateien gemäß der Open Packaging Conventions erlauben. Der Zugriff auf die Dokumentinhalte erfolgt allerdings nach wie vor über die ,,XML-API", also mit den Klassen in System.Xml oder (seit .NET 3.5) System.Xml.Linq. Damit wird das Zusammensetzen von URIs und das Durchsuchen von Beziehungen (GetRelationshipByType) ganz schnell zur Qual, ganz zu schweigen von der allgegenwärtigen Verwendung von Schemareferenzen.Eine goldene Regel für den Zugriff auf Open XML-Dateien: Immer über Standardwege entlang der Beziehungen auf die Bestandteile zugreifen und niemals mit einem absoluten Pfad. Letzteres mag im Einzelfall funktionieren, aber der physische Aufbau des Containers kann variieren. Solange den Beziehungen gefolgt wird, kann nichts schief gehen, denn nur diese kombinieren die logische ID mit dem wirklichen Pfad innerhalb des Containers.Das Open XML SDK als AlternativeZum Glück ist die System.IO.Packaging-API nicht die einzige Alternative. Seit einiger Zeit bietet Microsoft Entwicklern das Open XML SDK [3]. Es kaspelt die Klassen in System.IO.Packaging durch typisierte Klassen, die einen deutlich komfortableren mit dem Open XML-Container ermöglichen. Das bedeutet für Entwickler, dass die Zeit des manuellen Zusammensetzens von Content Types und Referenz-XML damit vorbei ist. Während die ,,rohe" Packaging-API nur ein Packagekennt, unterscheidet das SDK zwischen den drei Office-Applikationen und bietet je ein Objekt für WordProcessingDocument, SpreadsheetDocument und PresentationDocument sowie weitere spezielle Document Parts:CoreFilePropertiesPart coreProps = wDoc.AddCoreFilePropertiesPart(); bzw. generische Methoden für weitere Document Parts:Aber auch mit den Klassen des SDK muss der Entwickler beim Zugriff auf den Inhalt der Dokumente noch selbst Hand anlegen. Die verschiedenen Markup-Sprachen für Word, Excel und Powerpoint (WordProcessingML, SpreadsheetML und PresentationML) werden in Version 1.0 noch nicht unterstützt. Das gibt es erst in der 2.0 [4] des Open XML SDK, das derzeit bereits als Community Technical Preview (CTP) verfügbar ist. Bei Verwendung der Version 2.0 kann dann auch LINQ (Language Integrated Query) verwendet werden, um komplexe Inhalte zu durchsuchen. Damit kommt man der Idee schon erheblich näher, einfach zu beschreiben, WAS man tun möchte anstelle von WIE man es tun möchte FazitEs tut sich etwas auf dem Gebiet der Office-Dateiformate. Microsoft legt großen Wert darauf, Bibliotheken bereit zu stellen, die eine einfache Verwendung von Open XML auch ohne installierte Office-Versionen garantieren. Das ist Voraussetzung für eine Verbreitung dieser Technologie vor allem bei Server-Anwendungen. Zudem wird Open XML mit OpenXML4J [5] auch in der Java-Welt einfach verwendbar. Der Geschwindigkeitsvorteil einer solchen Lösung ist besonders bei größeren Datenmengen gegenüber COM Automation so gewaltig, dass sich der erhöhte Aufwand schnell rechtfertigt.Links&Literatur[1] - http://www.ecma-international.org/publications/standards/Ecma-376.htm[2] - http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=51463 [3] - http://www.microsoft.com/downloads/details.aspx?familyid=ad0b72fb-4a1d-4c52-bdb5-7dd7e816d046[4] - http://www.microsoft.com/downloads/details.aspx?familyid=C6E744E5-36E9-45F5-8D8C-331DF206E0D0[5] - http://www.openxml4j.org/ AutoreninfoJens Häupel ist als Platform Strategy Manager bei der Microsoft Deutschland GmbH tätig und beschäftigt sich von Anfang an mit Open XML. Sie können ihn über http://blogs.msdn.com/jensha erreichen.Peter Monadiemi