Vor 20 Jahren passierte für das Open Document Format die entscheidende ISO-Abstimmung: Anfang Mai 2006 billigten ISO und IEC das Format als künftigen internationalen Standard. Anschließend wurde ODF am 30. November 2006 als ISO/IEC 26300:2006 veröffentlicht. Damals wirkte das wie ein technisches Detail, heute erscheint es in einem anderen Licht. Regierungen und Behörden diskutieren wieder über digitale Souveränität, Plattformabhängigkeiten und Langzeitarchivierung. Plötzlich steht eine Frage erneut im Raum, die viele längst für entschieden hielten: Wem gehören digitale Dokumente eigentlich?

ODF ist dabei weit mehr als das Dateiformat von LibreOffice. Der Standard entstand aus der Idee, dass Dokumente dauerhaft lesbar, herstellerunabhängig nutzbar und technisch transparent sein sollen. Zwei Jahrzehnte später wirkt dieser Ansatz erstaunlich modern. Denn viele Probleme, die ODF lösen wollte, prägen heute erst recht den Alltag großer Organisationen: proprietäre Cloudplattformen, schwierige Datenmigrationen und die Frage, wie sich Informationen über Jahrzehnte hinweg archivieren lassen.

ODF war nie nur ein technisches Projekt. Das Format entwickelte sich früh zum Symbol im Konflikt zwischen offenen Standards und geschlossenen Ökosystemen – und zu einem der größten politischen Streitthemen der IT-Industrie der 2000er-Jahre.

Die Idee hinter ODF: Dokumente als offene Datenstrukturen

Anfang der 2000er dominierten proprietäre Binärformate die Office-Welt. Microsofts DOC-, XLS- und PPT-Dateien galten als faktische Industriestandards, doch ihre internen Strukturen waren nur teilweise dokumentiert. Wer vollständige Kompatibilität wollte, musste Microsoft Office kaufen.

ODF verfolgte einen anderen Ansatz. Das Format setzte konsequent auf XML und sollte vollständig offen spezifiziert sein. Inhalte, Formatierungen und Metadaten lagen getrennt voneinander vor. Ziel war nicht nur die Lesbarkeit für Menschen, sondern auch die automatisierte Verarbeitung durch Skripte oder Datenbanken.

Heute klingt das selbstverständlich. Anfang der 2000er gehörte es jedoch zu einem grundlegenden Paradigmenwechsel. XML galt damals als universelles Austauschformat für strukturierte Daten. ODF übertrug diese Idee auf Office-Dokumente.

Eine ODT-Datei besteht intern aus mehreren XML-Dateien. „content.xml“ enthält die eigentlichen Inhalte, „styles.xml“ die Formatdefinitionen. Metadaten liegen in „meta.xml“, anwendungsspezifische Einstellungen in „settings.xml“. Ein ZIP-Container fasst diese Bestandteile zusammen. Deshalb lässt sich eine ODT-Datei in „.zip“ umbenennen und mit jedem gewöhnlichen Packprogramm öffnen.

Die Architektur erinnert eher an moderne Webtechnologien als an klassische Office-Formate. Inhalte und Darstellung liegen getrennt vor – ähnlich wie HTML und CSS im Web. Diese Modularität erleichtert nicht nur die Analyse, sondern auch automatisierte Verarbeitung, Konvertierung und Archivierung.

Microsoft übernahm dieses Prinzip später für DOCX und XLSX. Auch Office Open XML basiert intern auf ZIP-Containern und XML-Dateien. Der Unterschied lag weniger in der Grundarchitektur als in der Frage, wie offen und interoperabel die Spezifikation tatsächlich ist.

Vom OpenOffice-Format zum ISO-Standard

Die Wurzeln von ODF liegen bei Sun Microsystems. Der damalige Eigentümer von StarOffice veröffentlichte den Quellcode 2000 als OpenOffice.org und brauchte ein standardisiertes Dateiformat für die freie Office-Suite.

2002 begann die Standardisierung bei OASIS, einem Industriekonsortium für offene Standards. Das Ziel war ein herstellerneutraler Dokumentstandard. 2005 verabschiedete OASIS ODF 1.0, 2006 folgte die ISO-Standardisierung als ISO/IEC 26300. Damit existierte erstmals ein vollständig offener internationaler Standard für Office-Dokumente.

Bemerkenswert ist aus heutiger Sicht, wie früh dabei Themen aufkamen, die inzwischen wieder unter dem Schlagwort „digitale Souveränität“ verhandelt werden. Schon damals argumentierten Befürworter, Staaten dürften ihre Dokumente nicht an einzelne Hersteller binden. Dokumentformate bestimmen schließlich, welche Software eine Organisation einsetzen muss und wie zugänglich Daten langfristig bleiben.

Behörden müssen Dokumente oft mehrere Jahrzehnte aufbewahren. Herstellergebundene Formate bergen dabei erhebliche Risiken: Spezifikationen ändern sich, Softwareprodukte verschwinden, Lizenzmodelle wechseln. Hinzu kommt: Wandern Dokumente in Cloudplattformen, entwickeln sich deren technische Grundlagen oft außerhalb der Kontrolle staatlicher Institutionen weiter. Ein offenes Format sollte dieses Problem entschärfen.

Retrieval Augmented Generation (RAG) kombiniert die Stärken von Textgenerierung und Information Retrieval, um präzise und kontextreiche Antworten auf komplexe Anfragen zu ermöglichen. Damit können Entwickler komplexe Anwendungen erstellen und die Leistungsfähigkeit moderner KI-Modelle voll ausschöpfen.

In unserem dreitägigen interaktiven Workshop KI für eigene Daten: Retrieval Augmented Generation (RAG) in der Praxis mit LangChain.js erhalten Sie eine fundierte Einführung in die Architektur und technischen Grundlagen von RAG sowie den Einsatz von LangChain.js. Sie lernen, wie Sie eigene KI-Lösungen auf Basis dieses Patterns entwickeln und diese sowohl in Cloud- als auch in On-Premise-Umgebungen implementieren.

Darüber hinaus erfahren Sie, wie Sie Prompts gezielt optimieren, KI-Anwendungen strukturiert aufbauen und eigene Datenquellen effizient in KI-Modelle integrieren. Sie lernen den Umgang mit APIs wie OpenAI und Azure OpenAI und entwickeln ein Verständnis für zentrale technische Aspekte moderner KI-Integrationen.

Jede Menge Praxis und Übungen

Der Workshop ist konsequent praxisorientiert aufgebaut und bietet eine interaktive Lernumgebung, in der Sie die Inhalte direkt umsetzen.

Sie entwickeln eigene KI-Agenten – von der Konzeption über die Implementierung bis hin zu realistischen Testszenarien. Dabei setzen Sie sowohl Cloud- als auch On-Premise-Umgebungen ein und lernen, wie sich RAG-basierte Systeme stabil und skalierbar betreiben lassen.

Durch die enge Verzahnung von Theorie und Praxis gewinnen Sie ein tiefes Verständnis für den Aufbau produktionsreifer KI-Anwendungen.

Von Erfahrungen aus der Praxis profitieren

Sie profitieren von der direkten Anleitung durch Ihren Trainer Gregor Biswanger, führender Experte für generative KI, Microsoft MVP für Azure AI und Web-App-Development.

Er arbeitet eng mit dem Microsoft-Produktteam rund um GitHub Copilot zusammen und begleitet Unternehmen bei der Entwicklung und Einführung moderner KI-Lösungen. Im Workshop vermittelt er praxisnahe Einblicke aus realen Projekten und zeigt, wie sich RAG-Architekturen effizient und produktionsreif umsetzen lassen.

Für wen ist dieser Workshop geeignet?

Der Workshop richtet sich an Entwickler, die ihre Fähigkeiten im Bereich moderner KI-Technologien erweitern und praxisnahe Erfahrung mit RAG-Systemen sammeln möchten. Er eignet sich sowohl für Einsteiger in die KI-Entwicklung als auch für erfahrene Entwickler, die ihr Wissen gezielt vertiefen wollen.

(ilk)

Der verschlüsselte Messenger Signal will nach Phishing-Attacken auf Politiker, Militärs und Journalisten in Deutschland zusätzliche Schutzmaßnahmen einführen. Wenn jemand zum ersten Mal eine Nachricht von einer unbekannten Nummer erhalte, würden künftig zusätzliche Warnhinweise angezeigt, sagte Meredith Whittaker, die Präsidentin der Non-Profit-Stiftung, die Signal betreibt, in einem Interview des Nachrichtenmagazins „Der Spiegel“.

Phishing-Angriffe gegen Mitglieder der Bundesregierung

Bei der jüngsten Phishing-Kampagne gegen Nutzer des beliebten Messenger-Dienstes standen vor allem Vertreter der Bundesregierung und der Regierungsparteien im Fokus. Betroffen waren unter anderem Bundestagspräsidentin Julia Klöckner (CDU) sowie die Kabinettsmitglieder Verena Hubertz (SPD) und Karin Prien (CDU). Verschiedene Sicherheitsexperten gehen davon aus, dass Angreifer aus Russland hinter der Cyberattacke stecken.

Whittaker betonte in dem Interview, der Messenger sei nicht gehackt worden. „Signal ist weiterhin sicher – unsere Verschlüsselung bleibt robust, und in unserem Open-Source-Code wurden keine Schwachstellen entdeckt. Wir sind durch unseren Erfolg offenbar zur Zielscheibe geworden, genauer gesagt durch unsere vielen hochrangigen Nutzerinnen und Nutzer.“ Diese seien durch Social Engineering manipuliert worden, Fehler zu begehen. „Das kann bei jedem Dienst passieren.“

Zusätzlicher Warnhinweis soll schützen

Die Signal-Chefin kündigte an, dass das Annehmen neuer, unbekannter Kontakte in Zukunft nicht mehr mit einem einzigen Klick möglich sein und zwingend einen Warnhinweis enthalten wird. „Wir prüfen noch weitere Ideen und werden dazu bald mehr bekannt geben. Und um es noch einmal klar zu sagen: Signal wird Nutzer niemals in einem zweiseitigen Chat kontaktieren, um sie nach ihrer PIN, ihrem Schlüssel oder anderen Informationen zu fragen.“

Auch, dass die Angreifer unter Namen wie „Signal Support“ auftraten, geriet in die Kritik. Das könne und wolle Signal aber nicht verhindern, sagte Whittaker. „Das ginge nur, wenn die App mitlesen und proaktiv Inhalte filtern würde.“ Ihr Dienste stehe schon jetzt unter „massivem Druck bestimmter Regierungen“ um „Inhalte zu scannen, bevor sie verschlüsselt werden“. Dem wolle man sich nicht beugen.

Signal kann auch Profilnamen nicht sehen

Prinzip bei Signal sei es, so Whittaker weiter, „möglichst wenig über unsere Nutzer oder gar deren Kommunikation zu wissen. Sie erfolgt verschlüsselt, auch für uns.“ Daher könne der Dienst nicht einmal Nutzernamen oder Kontakte einsehen.

Whittaker kritisierte, dass von der Phishing-Attacke betroffene Politikerinnen im Netz als digitale Analphabeten verunglimpft worden seien. „Das hat mich enttäuscht, aber nicht überrascht. Ich nehme in Teilen der Techszene durchaus eine gewisse Arroganz wahr, die nicht nett ist.“

(nie)