XML Dokumentenkonvertierung mit OpenOffice 1.1.x am Beispiel eines E-Learning Systems

Bild des Benutzers Axel Pospischil
Druckversion dieser SeiteDruckversion dieser SeiteSeite per E-Mail sendenSeite per E-Mail senden
figure pics/OO_125x50_2_free.png

In dieser Arbeit geht es darum, wie Schriftdokumente - insbesondere solche, die mit Officesystemen erstellt wurden - in E-Learningsysteme integriert werden können. Die inhaltlichen und strukturellen Informationen dabei zu bewahren, soll oberste Priorität haben. Es werden von mir nur offene Standards und Software eingesetzt, um eine innovative Weiterentwicklung und Integration in andere offene Software zu ermöglichen. Die Ergebnisse werden daher unter einer offenen Lizenz veröffentlicht. Das Modell soll leicht an gängige XML Standards adaptiert werden können und Schnittstellen zu gängigen E-Learningsystemen bieten. Als Referenzapplikation dient ein Konverter für OpenOffice/StarOffice Präsentationen (in der Version 1.1.x) für die E-Learning-Plattform ELAT. Die Arbeit entstand am Institut für grafische Datenverarbeitung, Darmstadt.

Lesen sie das ganze Dokument

Die gesamte Dokumentation können Sie im PDF Format herunterladen:
Zusätzliche Dokumente:
Im Anschluss lesen sie einige Auszüge.

Vorwort

Stellen Sie sich folgendes Szenario vor: Sie sind im Umfeld von Fort- und Weiterbildung tätig und möchten ihr Wissen elektronisch einem ausgesuchten Publikum zur Verfügung stellen. Sie besitzen das nötige Know How und auch die Kursmaterialien für die geforderte Aufgabe stehen Ihnen bereits zur Verfügung. Da sie bereits seit einigen Jahren im Geschäft sind und immer ihre Daten elektronisch erfasst haben, haben diverse Computersysteme und Dokumentformate Ihren Schreibtisch gesehen. Bisher ist also alles wie immer.
Ihr Auftraggeber möchte aber die Schulung innerhalb von 2 Wochen starten und besitzt bereits ein modernes Ausbildungszentrum mit entsprechender Ausstattung.
Zu ihren Auszubildenden gehören sowohl fest angestellte Mitarbeiter als auch freiberufliche, die sich jedoch nicht vor Ort befinden. Weil es sich um hoch bezahlte Spezialisten handelt, die nur in einem sehr begrenzten Zeitrahmen an Ort und Stelle zur Verfügung stehen, sollen der Kurs und die Leistungsnachweise zum Teil online stattfinden. Ein sehr heterogenes Publikum also.
Nun stellt Ihnen der zuständige Ingenieur das E-Learning System vor, in das Sie Ihre Kursdaten übertragen sollen. Es hört sich alles ganz vernünftig an, Wissensbausteine, Videounterstützung, interaktives Lernen. Beiläufig wird noch erwähnt, dass die Daten in XML-Dateien erfasst werden.
Sie denken sich vorerst nichts dabei, doch in den nächsten Tagen werden Sie graue Haare bekommen, wenn Ihnen die Inkompatibilitäten Ihrer Dokumenttypen und dieses E-Learning Systems bewusst werden.
Ihre didaktisch wohl durchdachten Powerpointpräsentationen werden zu einfachen Diashow ähnlichen Quicktimemovies reduziert. Ihre wohl strukturierten und mit zahlreichen Querverweisen versehenen Worddokumente sind mit der Version des Importfilters inkompatibel und Sie müssen alle Dokumente nochmals erstellen oder mit erheblichem Zeitaufwand korrigieren.

Dokumententypen in Officeprogrammen

am Beispiel OpenOffice

Hinweis zu Abkürzungen:

  • OpenOffice.org als Office Suite Softwarepaket wird im Folgenden als OOo bezeichnet.
  • Die Textverarbeitung Open Office Writer möchte ich als OOW oder OO Writer bezeichnen.
  • Das Präsentationsprogramm Open Office Impress wird mit OOI abgekürzt werden.
  • Das Office Programm Microsoft Word wird als Word bezeichnet.
  • Das E-Learning Programm Environment for Learning and Teaching ist ELAT.
  • Die Educational Modeling Language ist EML.

Einleitung

Das Management von Dokumenten streift viele Teilgebiete der Informationswissenschaften, die nicht alle der Informatik angehören. Bedenkt man, dass erst Ende der 90er Jahre internationale Standards zur Speicherung von Dokumenten (XML) verabschiedet wurden und die große Masse der Dokumenten Erfassungswerkzeuge gerade erst beginnt, ernsthaft diese Standards zu nutzen, so ist es nicht verwunderlich, das wir Anfang des 20. Jahrhunderts in großen Teilen unserer Dokumentenlandschaften immer noch mit geradezu steinzeitlich anmutenden Methoden arbeiten. Diese Arbeit hat mir gezeigt, wie viele verschiedene Aspekte für ein zukunftssicheres Dokumentenmanagement zu berücksichtigen sind und ich bin weit davon entfernt, eine allumfassende Lösung zu erkennen. Die größten Schwierigkeiten bestanden darin, die verschiedenen Teilbereiche Softwaretechnik, Programmierung und die Integration von Dokumentenstandards, wie XML - welches ein Universum für sich darstellt - unter einen Hut zu bringen und informationstechnisch korrekt umzusetzen.
In dieser Arbeit soll es darum gehen, wie Schriftdokumente - insbesondere solche, die mit Officesystemen erstellt wurden - in E-Learningsysteme integriert werden können. Die inhaltlichen und strukturellen Informationen dabei zu bewahren, soll oberste Priorität haben. Es werden von mir nur offene Standards und Software eingesetzt, um eine innovative Weiterentwicklung und Integration in andere offene Software zu ermöglichen. Die Ergebnisse werden daher unter einer offenen Lizenz veröffentlicht. Das Modell soll leicht an gängige XML Standards adaptiert werden können und Schnittstellen zu gängigen E-Learningsystemen bieten. Als Referenzapplikation dient ein Konverter für OpenOffice/StarOffice Präsentationen für die E-Learning Plattform ELAT. An vielen Stellen werde ich nur Ansätze zur Lösung liefern können, da ich hier selbst völliges Neuland betrete.

Diese Arbeit steht weiterhin ganz unter dem Motto OpenSource und offene Standards. Ich werde daher nicht nur auf die softwaretechnischen Details eingehen, sondern auch allgemeine Aspekte zu Anwendungsfällen bei der Erstellung und Konvertierung von Office Dokumenten aufzeigen. Mein vorrangiges Ziel ist es, Referenzplattformen wie OpenOffice und international einheitliche Standards in den Vordergrund zu rücken.

Als Werkzeuge kommt dabei vom Editor bis zur Entwicklungsumgebung und dem Betriebssystem ebenfalls nur Software zum Einsatz, die entweder der GPL oder ähnlichen offenen Lizenzen zur Verfügung stehen.
Ich muss leider auch an dieser Stelle - denn ich bin es schon gewohnt - darauf aufmerksam machen, dass dies nicht geschieht, um Geld zu sparen, sondern aus der Überzeugung heraus, dass langfristig eine moderne digitale Medienlandschaft nicht mit proprietären Software- oder Dokumentenstandards zukunftssicher gepflegt werden kann, auch wenn viele proprietäre Lösungen auf den ersten Blick scheinbar perfekte Lösungen anzubieten scheinen.
Vieles von dem was hier zur Sprache kommt, beschäftigt mich schon seit Ende der 80er Jahre, als ich auf einem Apple IIe und einem Commodore 64 (jeden Rechner hatte ich leihweise je 4 Wochen zur Verfügung), eine Facharbeit in Physik [1]  [1] Online einsehbar unter apos.de -> Themen -> Theorie der Kernreaktoren http://www.apos.de zu schreiben begann. Der Leser mag sich ausmalen, welche Schwierigkeiten damals die Umstellung vom einen ins andere Format machte - besonders die Sonderzeichen und Formeln bereiteten große Schwierigkeiten - vom Abenteuer Ausdruck gar nicht zu reden. Von da an begleiteten mich PC’s in vielen Tätigkeitsbereichen, vom Serienbrief über Tabellenberechnungen bis hin zu grafisch anspruchsvollen Dokumenten. Es gelang mir bisher, alle Dokumente bis auf den heutigen Rechner zu retten, jedoch nur, in dem ich Sie immer wieder regelmäßig konservierte, konvertierte, alte Software zur Not immer noch vorliegen hatte und niemals Word verwendete.

Internationale Standards versus proprietäre Standards

XML als internationaler Standard für Dokumente

Dokumente, die Jahre, vielleicht Jahrzehnte überdauern sollen, müssen in Formaten gespeichert sein, die weitblickend entworfen und international gepflegt werden. Industrielle Softwareprodukte mit meist kurzen Produkt- und Entwicklungszeiten werden meist nicht unter den Gesichtspunkten der Standardisierungsgremien, wie dem W3C http://www.w3c.org entworfen. Die wenigsten Softwarefirmen der Vergangenheit waren willens oder in der Lage, Mitarbeitern in die langwierigen Entscheidungs- und Evaluierungsprozesse über RFC’s (s. Glossar on page 1↓) einzubinden und so die Arbeit dieser Gremien in die Produkte einfinden zu lassen. Erst durch massiven Druck der Opensource Gemeinde und Firmen wie SUN (s. ), aber auch durch gerichtliche Entscheidungen müssen nun rein kommerzielle Softwarehersteller im Interesse des Allgemeinwohls ihre Schnittstellen offen legen. Verständlich war das ”closed source” Gebaren von Softwareherstellern in einer Zeit, in der Software alles und Service wenig bedeutete, in der Insellösungen an der Tagesordnung waren und der Kunde so gut wie alles kaufte, was seinen kurzfristigen Bedarf zufriedenstellte! Heute sind jedoch nicht nur die Kunden schlauer geworden, sondern Sie blicken auf den harten Alltag der vergangen Jahre zurück, in dem eine immer größere Anzahl wichtiger Firmendokumente aufbewahrt, weitergegeben und archiviert werden mussten und zahlreiche proprietäre Softwarestandards so manche Konvertierung vereitelten und die Pflege der Dokumente einem erneuten Erstellen an Aufwand fast gleichkam.
Zudem müssen angesichts immer umfangreicherer Standardsoftware aus dem Opensource-Bereich (s. Glossar on page 1↓) und dem Microsoft ”de facto” Standard bereits namhafte Firmen, wie Corel (WordPerfect) oder Lotus, jetzt IBM (Smartsuite) erkennen, dass Sie mit Ihren Dokumentenformaten über ein Nischendasein nicht hinauskommen werden.
Die heterogene Landschaft von Informationsdokumenten und die zunehmende Notwendigkeit der Vermischung unterschiedlicher Dokumententypen macht zudem die firmeneigene, nicht öffentliche (proprietäre) Schnittstelle immer unsinniger. Ja sie war es eigentlich schon immer, jedoch sahen viele Softwarefirmen ihre einzige Möglichkeit darin, ihr geistiges Eigentum zu schützen - meist auf Kosten der Endkunden - die nach einiger Zeit der Nutzung der Software feststellen mussten, dass Sie in eine Einbahnstraße geraten waren, aus der es nicht einmal mit Hilfe des Herstellers einen Ausweg gab. Zudem stellen immer noch viele Firmen die mannigfaltigen ”Fähigkeiten” Ihrer Software in den Vordergrund, ohne genügend Wert auf die Schnittstellenproblematik zu werfen.

Das Open Office Dokumentenformat als De Facto Standard?

Doch es ist Land in Sicht. Die Firma SUN - allen voran - schickte sich an, zusammen mit einer großen OpenSource-Gemeinde mit StarOffice/OpenOffice einen Dokumentenstandard zu erarbeiten, der den Grundforderungen an die heutigen Verfahren zu Verarbeitung und Speicherung von Dokumenten genügen sollte:
  1. Der Standard sollte sich auf einfache Weise nutzen lassen.
  2. Ein breites Spektrum von Anwendungen sollen unterstützt werden.
  3. Er muss kompatibel sein.
  4. Es soll einfach sein, Programme zu schreiben, die diese Dokumente verarbeiten.
  5. Die Anzahl optionaler Merkmale soll minimal sein, idealerweise Null.
  6. Dokumente sollten für Menschen lesbar und angemessen verständlich sein.
  7. Die Beschreibung sollte formal und präzise sein.
  8. Dokumente sollen leicht zu erstellen sein.
  9. Knappheit des Markup ist von minimaler Bedeutung, da Textdateien sehr gut gepackt werden können.
Man einigte sich, wie sollte es anders sein, auf XML. Wem es noch nicht aufgefallen sein sollte, ich erlaubte mir die obigen 9 Punkte genau den Anforderungen zu entlehnen, demnach seinerzeit XML entwickelt wurde. Sie sind allgemein für das Speichern von Dokumenten im informationstechnischen Umfeld gültig. Ich möchte hier davon ausgehen, dass der Leser dieser Arbeit mit XML vertraut ist bzw. das Internet bemüht, um sich damit vertraut zu machen und werde auf diese Spezifikation nicht weiter eingehen (siehe Anhang: on page 1↓).
Was die Dokumente von StarOffice/OpenOffice angeht, so einigte man sich zusätzlich auf die Tatsache, das ausnahmslos alle Dokumente einer einzigen Spezifikation [2]  [2] OOo XML Spezifikation http://xml.openoffice.org/xml_specification_draft.pdf, siehe auch [1] genügen sollten. Man erkannte, dass die Zukunft des Dokumentenmanagements sehr heterogen sein wird, und möchte eine zentrale Schnittstellenspezifikation anbieten, die den Anforderungen zukünftiger Informationslandschaften genügt.
Eine Ausnahme bildet die Beschreibung mathematischer Inhalte. Hier greift man auf den speziellen und bereits hervorragend ausgereiften XML Dialekt, den MathML http://www.w3.org/Math/ zurück.
Auch die immer größer werdende Gemeinde der Koffice Suite des weit verbreiteten Linux KDE Desktop Environments und die Gnome-Office Gemeinde haben sich diesem Standard angeschlossen. Man hat hier also den Schritt hin zu einem einheitlichen Officeformat vollzogen. Die IDA expert group http://europa.eu.int/ISPO/ida/ der europäischen Kommission spricht sich ebenfalls für eben dieses Format aus ([2]):

”Industry has taken important steps to address the requirements and concerns of the public sector regarding the use of document formats. The publication of the OpenOffice.Org and WordML formats has greatly improved the potential for interoperability of document processing.”

”Die Industrie hat wichtige Schritte zurückgelegt, um die Anforderungen und Bedürfnisse des öffentlichen Bereichs zu berücksichtigen, wenn es um die Verwendung von Dokument Formaten geht. Die Veröffentlichung der OpenOffice.org und WordML Formate hat das Potential zur Zusammenarbeit im Dokumentenmanagement erheblich erhöht.”

Die Organisation for the Advancement of Structured Information Standards (OASIS) hat es sich zur Aufgabe gemacht, die Entwicklung eines offenen XML-basierenden Dokumentenstandards zu betreuen. Hier befindet sich die Kernzelle auf dem Weg zu einem wirklich offenen Standard. Auf den Seiten der OASIS Komitees http://www.oasis-open.org/committees/ kann man entsprechend die aktuellen Aktivitäten zur Open Office Spezifikation verfolgen. Die wichtigsten Ziele des Open Office Dokumentenformates sind demnach: [3]  [3] Original in englischer Sprache, Übersetzt vom Autor, siehe Anhang on page 1↓.
  1. Es muss den Anforderungen an Office Dokumente genügen, die Text, Tabellenkalkulationen, Diagramme und graphische Dokumente enthalten,
  2. es muss kompatibel mit der W3C Extensible Markup Language (XML) v1.0 und den W3C Namespaces in der XML v1.0 Spezifikation sein,
  3. es muss einen hohen Grad an Informationen beibehalten können, um für das editieren von Dokumenten nützlich zu sein,
  4. es muss leicht sein, Transformationen mit XSLT oder anderen XML-basierten Sprachen und Tools durchzuführen,
  5. es muss den Inhalt und das Layout von Dokumenten getrennt aufbewahren, so dass beide Teile unabhängig von einander verarbeitet werden können, und
  6. es soll sich an ähnliche existierende Standards anlehnen, wo immer das möglich und erlaubt ist.
Eine interessante Untersuchung zum Thema findet der Leser in [3]. Das Bundesministerium für Sicherheit in der Informationstechnik hat eine Studie bei der Linux AG in Auftrag gegeben, deren über 100 seitiges Endergebnis viele Aspekte von OpenSource und offenen Standards betrachtet. Hier wird besonders auch der Sicherheitsaspekt eine Dokumentenformats detailliert erörtert.
An dieser Stelle sei nur angemerkt, dass Behörden eine Aufbewahrungspflicht von Dokumenten bis zu 60 Jahren haben und Standards dementsprechend lange lesbar sein müssen!

Und Microsoft?

Die Firma Microsoft hat nun endlich nach jahrelangem Tauziehen [4]  [4] siehe [4] und auch [5] mit Office 2003 drei verschiedene (!) Standards auf den Markt gebracht, die zwar offen liegen, leider nicht zueinander voll kompatibel sind, jedoch den Anforderungen an ein wirklich offenes Dokumentenformat im oben genannten Sinne weitestgehend entsprechen. Noch Ende des Jahres 2002 war keine endgültige Aussage aus Redmond zum Thema XML zu hören! Bisher war eine Konvertierung von Microsoft Officedokumenten nur durch proprietäre Blackbox DLLs möglich, die letztendlich die Dokumenteninhalte im Microsoft eigenen RTF Format speicherten. Andere Firmen, wie Lotus bildeten da keine Ausnahme.
Löblich ist also das Ansinnen zu nennen, XML als Standard zu benutzen jedoch die Umsetzung zeigt, dass hier wieder Schranken errichtet werden, wo keine sein sollten. Die XML Referenz der OfficeML-Schema Familie, wie Microsoft seine ”patentierte” Schöpfung von ”Dokumenteninhalten basierend auf XML in einer Datei” nennt, finden sich auf einer eigenen MS Office Homepage http://www.microsoft.com/office/xml, welche leider zu 80% dazu einlädt, sich nicht mit dem eigentlichen Schema, sondern linzenzrechtlichen und patentrechtlichen Fragen auseinanderzusetzen [5]  [5] Man möge dem Autor seine offensichtlich einseitige Meinung in diesem Punkte verzeihen, doch er ist der Ansicht, dass Firmen, die in diesen Größenordnungen Software entwickeln in noch größerem Mass auch zur lizenzrechtlichen Freigabe solch grundlegender Datenstrukturen gedrängt werden müssen. Strukturen, die ohne das Know How jahrzehntelanger öffentlich finanzierter Forschungs- und Entwicklungsarbeiten unmöglich wären!. Ich werde hier auf die Microsoft eigenen Schemas nicht eingehen, da Sie in meinen Augen auf Dauer den Standardisierungsanforderungen der IDA, sowie der ISO nicht standhalten werden können und zudem immer Linzenzproblematiken für die Entwicklung freier Software einhergehen werden [6]  [6] siehe [6].

Was ein modernes Dokumentenformat leisten muss

Eine der wichtigsten Forderungen an ein zukunftsweisendes Dokumentenformat ist die modulare und damit eindeutige Trennung von Inhalt, Form und die Möglichkeit der Speicherung von Metadaten. Dies betrifft jedoch nicht allein Tatsache, dass - wie in allen Markupsprachen üblich - Textinhalte und Formatierungszuordungen eindeutig getrennt werden. Ein modernes Dokumentenformat muss neben dem Inhalt auch folgende Daten mit im Dokument abspeichern:
  • Metadaten (über den Autor, Zeitlich relevante Daten)
  • Stil (Formate, die den Dokumenten gespeichert werden)
  • Applikationsabhängige Daten (z.B. Darstellung auf dem Bildschirm, Darstellungsebene, Druckeinstellungen)
  • Zusätzliche Informationen über enthaltene Dateien (MIME Typ, Verschlüsselungsverfahren)
  • Bilddateien in ursprünglicher binärer Form
  • GUI Informationen zu Dokumentenmakros
  • die Dokumentenmakros selbst in einer spezifischen Makrosprache
  • Eingebettete Objekte (entweder Fremddokumente im Binärformat, oder XML Dokumente im eigenen Format)
Die genaue Dokumentation des OOo Dateiformats kann auf http://xml.openoffice.org/ eingesehen werden. In Abschnitt gehe ich nochmals auf die einzelnen Dokumententypen ein, insbesondere auf Textdokumente und Präsentationsdokumente, da diese im E-Learning Umfeld die bedeutendste Rollen spielen. Ein ausgezeichnete Dokumentation kann man online einsehen: [7] [7]  [7] Das Buch befindet sich in der Entstehung und ist, wie viele Werke dieser Art unter der Creative Common License http://creativecommons.org/licenses/by-nc-nd/2.0/ veröffentlicht, kann zur Zeit hier http://books.evc-cit.info/ online gelesen und als HTML heruntergeladen werden. In Zukunft wird es als GNU Free Documentation License http://www.fsf.org/licenses/fdl.html weiterhin frei erhältlich sein.. Ich werde im Folgenden auf für die Konvertierung in andere Formate ausschlaggebenden Definitionen des OOo Formates eingehen. Der Leser möge sich bitte die eben genannten Links zum besseren Verständnis zu Gemüte führen.
Die Firma SUN wird nach Aussage ihres Mitarbeiters Tim Bray (Sept. 2004) zudem nicht nur die OfficeML Konverter in StarOffice einbauen, sondern es soll versucht werden, das OOo Format bei der ISO standardisieren zu lassen. Ein, wie ich finde sehr zukunftsweisendes Ansinnen. Zu diesem Zweck wurde das OO-Dateiformat an ein Komitee namens OASIS http://www.oasis-open.org/committees/office/ zur Erarbeitung und Weiterentwicklung übergeben.

Eine Entscheidung...

Ich habe mich nicht nur auf Grund dieser Tatsachen, sondern auf Grund meiner langjährigen positiven Erfahrung mit echten offenen Standards und deren hervorragenden (wenngleich auch meist recht komplexen) Dokumentation für das Dokumentenformat von OpenOffice entschieden. Im Hinblick auf das Ziel Office Dokumente und E-Learning Applikation miteinander zu verbinden ist es sinnvoll, als Ausgangsbasis das Office Dokument zu nehmen und eine Exportfunktion zu integrieren. Im Gegensatz dazu scheint es mir weniger sinnvoll, die E-Learning Applikation selbst zu verändern oder dort einen Filter zu implementieren, da wohl in den seltensten Fällen ein direkter Eingriff in eine solch komplexe Software möglich ist und die heterogene Landschaft von E-Learningsystemen dem Entwickler kaum die nötigen Informationen zur Verfügung stellt. Doch dazu im zweiten Teil dieser Arbeit mehr.

References

Lesen sie das ganze Dokument

Die gesamte Dokumentation können Sie im PDF Format herunterladen:
Zusätzliche Dokumente:

Newsfeed

Newsfeeds abonnieren