Es ist gar noch nicht lange her, als Tim Berners-Lee das Wiederaufleben der HTML-Arbeitsgruppe des W3C verkündete. Das wäre an sich eine freudige Nachricht, wenn es da nicht schon seit Ewigkeiten die XHTML-Arbeitsgruppe gäbe, bei der jedoch Fortschritte nur mit der zeitlichen Lupe festzustellen sind.
Wer sich mit einem Vergleich von (X)HTML 5 und XHTML 2 über mögliche kommende Neuerungen informieren will, dem sei die Übersetzung des XHTML.com-Artikels (X)HTML 5 und XHTML 2 im Vergleich von Jens Meiert empfohlen.
Gary Edwards denkt in seinem Open Stack-Blog genau richtig: Die Antwort, um das OpenDocument-Format (ODF) weltweit zum Durchbruch zu verhelfen, liegt allein darin, dass Microsoft Office-Anwender und alle Produkte, die mit MS Office zusammenarbeiten, ODF als Standardformat anwenden oder zumindest damit umgehen können.
Dieses Problem wird seiner Meinung nach – und da schließe ich mich an – bisher viel zu wenig aufgegriffen. Mit Konvertern allein ist dies nicht zu schaffen. Erstens sind die Konverter von Microsoft/Novell und Sun zu unzuverlässig, um damit Dokumente zwischen MS Office und anderen Programmen produktiv austauschen zu können. Zweitens bleiben alle Produkte, die auf MS Office aufbauen oder sich daran anschließen, von den Konvertern unberührt – sie erzeugen wieder binäre Microsoft-Dateien oder OOXML-Dateien.
All dies geht die OpenDocument Foundation mutig an, um das Monopol von Microsoft zu brechen. Nicht um des Monopols willen, sondern zum Wohl und der Langlebigkeit des geistiges Eigentums der Dokumenten-Ersteller. (Würde sich Microsoft selbst 100%ig an alle Spezifikationen halten, die es mitentwickelt oder kreiert, wäre dessen Formate-Monopol weniger tragisch. Glaubt jemand eigentlich wirklich, dass OOXML, das Microsoft der Ecma vorgelegt hat, exakt das selbe ist, wie es in MSO 2007 implementiert wurde? Oder dass jemand anderes als Microsoft OOXML vollständig umsetzen kann?)
Die Antworten dafür lauten:
- daVinci ODF-Plugin und
- daVinci InfoSet Engine & API.
Das daVinci ODF-Plugin für Microsoft Office 98-2007 habe ich bereits vorgestellt, ist (angeblich) bereits bei der Verwaltung in Massachusetts als Testversion mit ODF v1.0 im Einsatz und soll mit Hilfe der Erweiterungen von ODF v1.2 noch im Jahr 2007 seine Perfektion und Marktreife erlangen.
InfoSet soll eine vollständige ODF-Konvertierungs- und Darstellungsanwendung werden, an der sich andere Produkte anstöpseln können, um mit ODF einfach arbeiten zu können (ähnlich dem ODF Toolkit Project von OpenOffice.org). Ein Veröffentlichungstermin dafür ist (leider) noch nicht bekannt. Die Arbeiten sind noch im Anfangsstadium.
Probleme mit der endgültigen Version von MS Office 2007
Interessant ist noch die Bemerkung von Gary Edwards, dass das Verhalten gegenüber ZIP-Dateipaketen in der endgültigen Version von MS Office 2007 anders sei als das in vorherigen Beta-Versionen. Microsoft hat anscheinend in letzter Sekunde die Systemeinstellungen so geändert, dass jedes ZIP-Dateipaket (wie ODF und OOXML eines sind) bei Doppelklick automatisch vom Microsoft’schen Konverter umgewandelt und in MS Office 2007 dargestellt wird. Somit werden alle nicht-microsoftschen Konverter (wie daVinci oder der von Sun) übergangen. Dieses Problem auszumerzen verzögert die Entwicklung von daVinci weiter.
Microsoft erklärt ODF und OOXML für Sieger
Vor ein paar Tagen hat Microsoft bzw. OOXML-Mitentwickler Brian Jones beide Dateiformate als Sieger klärt im „Formatekrieg“, nachdem Novell die erste Testversion seines OOXML-Konverters für seine eigene OpenOffice.org-Version veröffentlicht hat. Die Erklärung von Brian Jones finde ich a) witzig (denn noch ist gar nichts endgültig entschieden) und b) erheiternd (denn wenn Microsoft jemand anderen als sich selbst ebenfalls als Sieger bezeichnet anstatt als Verlierer, dann heißt das eigentlich, dass sich Microsoft selbst als (nahen) Verlierer sieht).
Novells Konverter dürfte übrigens auf wenig Gegenliebe in der OpenSource-Welt stoßen, denn er ist genau so schlecht wie der ODF-Konverter von Microsoft und baut auf Mono auf, einer OS-Variante von Microsofts .NET, anstatt das in OpenOffice.org bereits verwendete Java oder andere Techniken zu verwenden.
Der OpenSource-Gedanke greift um sich. Nicht nur, dass immer mehr Firmen Programme in OS veröffentlichen, um eine erweitere Entwickler- und Testergemeinde zu bekommen, oder sich an bestehenden OS-Projekten beteiligen (für mich persönlich ist die Beteilung von Sun Microsystems und QUALCOMM an Mozilla Thunderbird (Eudora)/Lightning/Sunbird z.B. ein wichtiger Schritt). Nein, auch im Bereich Technik/Produktion/Forschung gibt es diesen Gedanken, der den Namen Open Innovation trägt.
Das österreichische Wirtschaftsministerium unterstützt Open Innovation mit dem Projekt innovate! austria. Der Fokus dabei liegt auf einer starken Integration in den Entwicklungsprozess von Kunden, Lieferanten, Universitäten, Forschungsinstituten bis hin zu Mitbewerbern
.
Als Beispiel dafür werden unter anderem OScar und Wikipedia angegeben. OScar ist ein Projekt, das sich zum Ziel gesetzt hat, nach OpenSource-Richtlinien ein umweltfreundliches Automobil für den Stadtverkehr zu entwerfen.
Tja, die Sache rollt und ist nicht mehr aufzuhalten. Man mag über Richard Stallman meinen, was man will, aber sein Einsatz trägt viele Früchte – nicht nur dort, wo er sich explizit engagiert.
Das Illinois Center for Information Technology Accessibility stellt auf seiner Website einen Open Document Format (ODF) Accessibility Evaluator zur Verfügung, mit dessen Hilfe das hochgeladene (bis zu 2 MB große) ODF-Dokument auf seine Zugänglichkeit überprüft werden kann.
Das Projekt befindet sich noch im Alpha-Status. Darum werden derzeit nur rudimentäre Eigenschaften geprüft wie Dokumententitel, Kopfzeilen, Alternativtexte für Bilder usw.
Finde ich gut, denn nicht nur Webseiten sollten auf Zugänglichkeit getrimmt werden.
Auf zum Test: Open Document Format (ODF) Accessibility Evaluator
Seit einer Weile wird in einschlägigen Kreisen über Neuerungen in OpenDocument v1.2 diskutiert. (OpenDocument v1.1 mit kleinen Zugänglichkeitsverbesserungen wurde Anfang Februar offiziell von der OASIS verabschiedet.)
Als gröbste Arbeiten gelten
1) das Auslagern des ZIP-Verpackungs-Abschnittes in ein eigenes Dokument (soll die Wartbarkeit erleichtern sowie ermöglichen, dass auch andere Spezifikationen diesen Abschnitt benutzen können wie z.B. von Adobe angedacht für sein Open eBook Publication Structure Container Format, kurz OCF);
2) die Einarbeitung der Ergebnisse des Metadaten-Unterausschusses (subcommittee) der OpenDocument-Arbeitsgruppe (ermöglicht unter anderem eine genauere Beschreibung und insgesamt leichteren Umgang mit fremden, undokumentierten Dateiformatteilen, vor allem in Microsofts Binärformaten) und
3) die Einarbeitung der Ergebnisse des OpenFormula-Unterausschusses der OpenDocument-Arbeitsgruppe (enthält eine vollständige Spezifikation für Tabellenkalkulationen wie Calc oder Excel). Siehe auch David A. Wheelers OpenFormula-Einführung.
4) die Einarbeitung der neuen Ergebnisse des Accessibility-Unterausschusses der OpenDocument-Arbeitsgruppe (der auch schon gute Arbeit an ODF v1.1 gemacht hat).
Die Formelbeschreibungen werden wahrscheinlich in ein eigenes Dokument ausgegliedert. Im Grobentwurf OpenFormula 2005-02-26 wurde diese Auslagerung favorisiert, und der Aufbau der aktuellen OpenFormula-Entwürfe lässt auf eine quasi-eigene, nicht in die OpenDocument-Beschreibung eingearbeitete Spezifikation schließen, die jedoch beide aufeinander verweisen und ergänzen.
Die „kleineren” Arbeiten betreffen verschiedene Element-Formatierungen, die geändert oder hinzugefügt werden sollen. Subtables sollen z.B. missbilligt werden (also in neuen Dokumenten nicht mehr angewendet, da dies in einer späteren Spezifikation gänzlich entfallen könnte), neue Nummerierungselemente sollen hinzukommen sowie page-break/column-break zum bestehenden line-break. Auch gibt es einige Vorschläge, um die Zusammenarbeit mit Microsoft Office-Dateien zu verbessern/erleichtern.
Florian Reuter hat dazu am 20.11.2006 in der Mailingliste einige Vorschläge gemacht: Suggested ODF1.2 items. Am 12.01.2007 gab es einen ersten Zwischenbericht: ODF 1.2 Draft 1.
Außerdem soll mit ODF 1.2 endlich eingeführt werden, dass für eine Anwendung (z.B. OpenOffice.org) unbekannte XML-Teile im Dokument unangetastet bleiben müssen und nicht verändert werden dürfen. Wenn also mit MS Office gespeicherte Daten in OpenOffice.org nicht erkannt werden, werden diese nicht überschrieben und gehen nicht verloren. Sie werden einfach ignoriert und mit MSO kann man damit später wieder weiterarbeiten. (Bei ODF 1.0 und 1.1 steht im betreffenden Spezifikationsabschnitt 1.5 noch „… Conforming applications that read and write documents may preserve foreign elements and attributes. …”) – Im langen Artikel Open Stack: OpenDocument as the perfect Microsoft Office file format steht ein bisschen zu diesem Thema.
Bei OASIS zur Abstimmung gebracht werden soll ODF 1.2 Ende des Sommers 2007.
Bei Anmerkungen zu ODF 1.2 sei die OD Mailingliste empfohlen.
OpenOffice.org fügt Microsoft Office-Funktionen hinzu
Nur nebensächlich für dieses Thema aber wichtig für die Zusammenarbeit mit Microsoft Office ist folgende Bemerkung aus dem GulliFOSS-Weblog: Um Layoutprobleme bei der Umwandlung MSO-Formate <> ODT zu minimieren, werden die in OOo am meisten vermissten oder falsch interpretierten Funktionen aus MSO eingebaut/verbessert. – Wann dies geplant ist, steht jedoch nicht dort. Das könnte (in kleinen Schritten) auf die 2.x-Reihe zutreffen oder (im großen Maßstab) auf das künftige OOo 3.0.