In unserem leckeren Häppchen-Überblick servieren wir alles, was es zwar nicht in die News geschafft hat, wir aber dennoch für spannend halten:

• Die Runtime‑Validierungsbibliothek Zod bekommt mit Version 4.5 ein neues Feature: Zod-Schemata lassen sich mit z.compile(schema) nun vorab kompilieren, was späteres Parsing deutlich beschleunigt. Der Tempogewinn kommt auch dadurch zustande, dass ein einfaches z.string()‑Schema gegenüber Zod 4.4 jetzt fast 10-mal weniger Speicher belegt.
• Der in Elixir und Phoenix geschriebene Fediverse-Server abuuba liegt in Version 1.0 vor. Das Open-Source-Tool fungiert als Drop‑in‑Ersatz für Mastodon und ist laut Benchmarks auf der Entwickler-Webseite deutlich schneller und wesentlich ressourcenschonender als das Original. abuuba bietet die gleichen Funktionen wie Mastodon, unterstützt sämtliche 289 seiner Endpoints und ist kompatibel zu ActivityPub. Sein Entwickler betont, dass abuuba noch nicht für den Produktivbetrieb geeignet ist.
• Qt schickt den Qt AI Assistant in Rente. Gleich mehrere spezialisierte Developer‑Agents sollen nun die Aufgaben des KI-Chatbots übernehmen, direkt in den Workflow integriert sein und Aufgaben automatisiert ausführen können. Der Qt AI Assistant ist ab dem 30. September nicht mehr Teil von Qt Creator und der Support endet am 31. Dezember dieses Jahres.

• Visual Studio Code 1.136 erlaubt experimentell die Personalisierung des Chat-Hintergrunds im Agents Window, wahlweise mit Codicons-Muster oder eigenen Bildern.
• PyTorch 2.14 setzt den Weg fort, den die 2x-Reihe begonnen hat: von einem Research-First-Framework hin zu einer vereinheitlichten, hardwareagnostischen Plattform für Training in der Produktion und Inferenz in großem Maßstab. Version 2.14 verbessert laut dem PyTorch-Blog Performance, Zuverlässigkeit sowie Hardware-Support und bringt unter anderem das neue GPU-Mathe-Backend NVGEMM mit.

• Der letzte Release Candidate für Python 3.15 ist erschienen, bevor das finale Release am 1. Oktober eintreffen soll. Ab dem jetzigen Zeitpunkt finden keine ABI-Änderungen mehr statt, und das Python-Team möchte möglichst wenig am Code ändern. Anbieter von Third-Party-Python-Projekten sollen sich nun auf Python 3.15 vorbereiten.
• Die BOB-Konferenz 2027, die am 27. Februar stattfinden soll, sucht wieder Vortragende. Themen sind insbesondere funktionale Programmierung, Datenstrukturen, formale Methoden, Architektur usw.
• Embedded-Entwicklung mit der IDE von IAR Systems ist neben Windows nun auch nativ für Linux möglich. Das Tochterunternehmen der Qt Group hat seine Entwicklungsumgebung für den Cross-Plattform-Einsatz in sicherheits- und compliance-kritischen Embedded-Projekten um Linux-Support erweitert.
• Das Rust-Team hat die Coreutils 0.11 veröffentlicht, deren Diagnose-Engine jetzt auf Ariadne basiert. Zudem erhöht die Version die Kompatibilität zur GNU-Variante.

Solltest du ein schmackhaftes Thema vermissen, freuen wir uns über deine Mail.

(mro)

Wer kontrolliert unsere Dokumente – und wer entscheidet darüber, ob sie auch in zehn oder zwanzig Jahren noch lesbar, bearbeitbar und unabhängig von einem einzelnen Anbieter nutzbar sind? Für Italo Vignoli von der Document Foundation ist die Antwort klar: Die Debatte um digitale Souveränität beginnt nicht bei der Wahl einer Office-Suite, sondern beim Dateiformat. Im Gespräch erklärt er, warum er DOCX, XLSX und PPTX als strategisches Lock-in betrachtet, weshalb ODF aus seiner Sicht weit mehr ist als eine technische Alternative – und warum Behörden, Unternehmen und private Nutzer ihre Dokumentstrategie grundlegend überdenken sollten.

Der TDF-Blog war lange vor allem für Nachrichten rund um LibreOffice bekannt. Warum habt ihr gerade jetzt eine Reihe über offene Formate, Standards und digitale Souveränität gestartet?

Der TDF-Blog wurde eingerichtet, um über sämtliche Aktivitäten des Projekts zu berichten – nicht nur über LibreOffice, sondern auch über das Dokumentformat ODF, die von Document Liberation entwickelten Filter für ältere Formate, die Unterstützung politischer Initiativen zugunsten von FOSS sowie groß angelegte Migrationsprojekte. Die Liste ist tatsächlich sehr lang.

Die Idee für die aktuelle Artikelserie entstand im Vorfeld des zwanzigsten Jahrestags der Verabschiedung von ODF als OASIS-Standard im Mai 2025 – als Würdigung dieses außerordentlich wichtigen Meilensteins für FOSS. Das äußerst positive Feedback auf die ersten Artikel, die von verschiedenen Medien kommentiert und aufgegriffen wurden, ermutigte uns, die Reihe fortzusetzen und zudem auf weitere Themen auszuweiten, etwa auf digitale Souveränität – die eng mit ODF verbunden ist – und proprietäre Formate.

Die Anzahl der auf den Inhalten dieser Beitragsreihe beruhenden Artikel sowie das Interesse zahlreicher Journalisten an den behandelten Themen haben uns dazu bewogen, weiterzumachen – ursprünglich hatten wir eine Reihe von etwa zwanzig Artikeln vorgesehen – und uns an Diskussionen über digitale Souveränität zu beteiligen, nicht zuletzt, weil dieses Thema zu einem gemeinsamen Anliegen geworden ist.

Warum beginnt die Debatte über freie und unabhängige Bürosoftware bei Dateiformaten und nicht bei der Wahl der Anwendung?

In einer idealen Welt gäbe es ausschließlich Open-Source-Softwarelösungen, die sowohl bei Komponenten als auch bei Dokumentformaten nur offene Standards nutzen. Leider ist die Welt, in der wir leben, alles andere als ideal. Denn seit Jahrzehnten wurde die Kontrolle über Technologie völlig unkritisch in die Hände von Big Tech gelegt – mit den Folgen, die wir alle kennen.

Zu diesen Folgen zählt genau jenes proprietäre Format, das sich als offener Standard ausgibt und uns dazu zwingt, die Diskussion bei den Formaten statt bei den Anwendungen zu beginnen. Tatsächlich verwenden selbst die meisten Open-Source-Office-Suiten – oder jene, die sich als solche bezeichnen – dieses proprietäre Format nativ. Damit vergrößern sie Microsofts Kontrolle über Dokumente, denn Microsoft definiert das Format und entscheidet somit über dessen Interoperabilität.

„Open Source“, „offenes Format“ und „offener Standard“ werden häufig gleichbedeutend verwendet. Worin liegt der Unterschied – und warum sollte er nichttechnische Nutzer interessieren?

Die drei Begriffe unterscheiden sich grundsätzlich, weil sie sich auf völlig verschiedene Dinge beziehen: „Open Source“ bezeichnet Software, deren Quellcode verfügbar gemacht wird, damit er untersucht, verändert, verbessert und weiterverbreitet werden kann. Ein „offenes Format“ bezeichnet ein Dokumentformat, das transparent entwickelt, gut dokumentiert, versionskontrolliert und für kompetente Entwickler leicht implementierbar ist. Ein „offener Standard“ bezieht sich auf Elemente – Hardware, Software und mehr –, deren Eigenschaften eine einfache Wiederverwendung ohne Einschränkungen oder Begrenzungen ermöglichen.

LibreOffice ist Open Source, weil seine Copyleft-Lizenz MPL Nutzung, Untersuchung, Veränderung und Verbreitung erlaubt. ODF ist ein offenes Format, weil es von einer unabhängigen Organisation öffentlich und transparent entwickelt, entsprechend der jeweiligen Version konsistent dokumentiert, versionskontrolliert und leicht implementierbar ist. ODF ist zugleich ein offener Standard – teilweise aus denselben Gründen, aus denen es ein offenes Format ist, und teilweise, weil es andere offene Standards wiederverwendet und keinerlei proprietäre Elemente enthält.

DOCX, XLSX und PPTX werden fast überall verwendet. Wo genau entsteht dadurch aus Ihrer Sicht eine problematische Abhängigkeit von einzelnen Anbietern?

DOCX, XLSX und PPTX sind proprietäre Formate, weil sie eine Version des Formats verwenden, die als „Transitional“ bezeichnet wird, da sie weiterhin mit den proprietären Formaten DOC, XLS und PPT verknüpft ist. Diese Variante sollte 2010 durch eine Standardversion namens „Strict“ ersetzt und anschließend vollständig abgeschafft werden – gerade weil sie proprietär war.

Damals setzte ISO auf Microsoft, das all dies bei der Genehmigung des Formats zugesichert hatte. Von einer Standardisierung kann dabei in keiner Weise gesprochen werden, denn kaum etwas ist weiter von einem Standard entfernt als das Microsoft-Format – einschließlich der „Strict“-Version. ISO glaubte damals nicht jenen, die darin eine Strategie sahen, Zeit zu gewinnen und sicherzustellen, dass sich nichts ändert, damit das Microsoft-Office-Format dauerhaft proprietär bleibt. Die Geschichte hat uns recht gegeben.

DOCX, XLSX und PPTX – die ich jetzt unter dem offiziellen Namen des Formats, OOXML, zusammenfassen werde – sind unabhängig von der Software, dem Anwendungsfall oder dem Nutzertyp ein Problem. Proprietäre Formate sind immer ein Problem, weil sie von einem einzigen Unternehmen auf Grundlage eigener Geschäftsstrategien definiert werden, die nie mit den Interessen der Nutzer übereinstimmen.

Darüber hinaus sind diese Formate gezielt darauf ausgelegt, einen Lock-in zu erzeugen, der äußerst schwer zu erkennen ist, sofern man die technischen Eigenschaften des Formats nicht eingehend untersucht. Selbst die Softwareunternehmen, die sich entschieden haben, das OOXML-Format nativ zu unterstützen, sind sich dessen nicht bewusst, weil sie es nicht untersucht haben. Sie verwenden also ein Format, das ihre eigenen Nutzer bindet – allerdings zum Vorteil Microsofts, nicht zu ihrem eigenen.

Ich verstehe vollkommen, dass all dies wie Science-Fiction klingt. Leider handelt es sich jedoch um eine Realität, die selbst dann nicht erfasst wird, wenn man sie einfach – oder besser: so einfach wie möglich – erklärt. Leider gibt es keinen wirklich einfachen Weg, das Problem zu erläutern, denn es wurde bis ins kleinste Detail so konzipiert, dass es äußerst kompliziert ist.

Wie gut funktioniert die tägliche Arbeit mit ODF heute tatsächlich? Bei welchen Dokumenttypen ist der Wechsel unkompliziert, und wo sollten Nutzer realistischerweise Schwierigkeiten erwarten – etwa bei Makros, spezialisierten Vorlagen oder komplexen Tabellen?

ODF ist hinsichtlich der Funktionalität des Formats genauso gut wie OOXML. Es kann daher für jede Aufgabe und in jeder Anwendung problemlos eingesetzt werden und beeinträchtigt die Interoperabilität von Dateien nicht, da es vollständig dokumentiert ist.

OOXML hingegen wurde bewusst so konzipiert, dass es Interoperabilitätsprobleme verursacht. Es ist auch nicht so dokumentiert, dass dieses Problem entschärft würde, da sich die Formatspezifikationen durch regelmäßige Sicherheitsupdates auf nicht dokumentierte und unsichtbare Weise verändern.

Folglich werden Interoperabilitätsprobleme durch OOXML und nicht durch ODF verursacht. Daher sollten die Kosten dafür von OOXML-Nutzern getragen werden, nicht von ODF-Nutzern. Zudem gilt: Wenn ein Dokument im OOXML-Format korrekt erstellt wurde, lässt es sich auch im ODF-Format korrekt öffnen.

Ich nutze seit Jahren Linux und öffne daher alle OOXML-Dateien, die ich erhalte, mit LibreOffice. Es konvertiert sie sofort in das native ODF-Format. Dabei hatte ich noch nie ein Problem. Wenn ich einer Kontaktperson eine Datei im OOXML-Format senden muss, konvertiere ich die ODF-Datei in OOXML. Auch in diesem Fall hatte ich noch nie ein Problem. In meinem Beruf verfasse ich sehr viele Dokumente – wir sprechen von Tausenden Dateien.

Natürlich werden viele Dateien eher unsystematisch erstellt – und Sie können sich kaum vorstellen, wie kreativ Menschen dabei sein können. Deshalb öffnen sie sich in beide Richtungen nicht korrekt.

Meiner Erfahrung nach braucht es weniger Zeit, eine Datei zu korrigieren, als sich über Inkompatibilität zu beklagen, auch wenn sich die meisten Nutzer für Letzteres entscheiden. Solange wir jedoch ein Format haben, das gezielt dafür entwickelt wurde, Interoperabilitätsprobleme zu verursachen, wird sich die Situation nicht grundlegend ändern.

Makros wiederum sind ein komplett eigenes Problem, weil sie in keiner Weise zur Welt der Standards gehören. Eine ODF-Datei mit Makros ist mit einer OOXML-Datei mit Makros identisch – sie ist also mit jedem Standard unvereinbar, sofern keine neutrale Sprache wie Python verwendet wird.

Makros gehören zur ersten Generation von Office-Suiten und ergeben heute nur noch in sehr wenigen Fällen Sinn. Das liegt auch daran, dass viele dieser Funktionen inzwischen direkt in die Software integriert sind. Außerdem zählen sie zu den wichtigsten Sicherheitslücken und sollten deshalb niemals eingesetzt werden – insbesondere nicht in Umgebungen, die besonders stark von Angriffen bedroht sind.

Viele Organisationen meinen: „Wir würden gerne offene Formate nutzen, aber unsere Kunden und Partner schicken uns einfach Microsoft-Dateien.“ Wie lautet Ihre pragmatische Antwort darauf?

Die pragmatische Lösung ist zugleich die einfachste. Es handelt sich um die Methode, die wir im Migrationsprotokoll empfehlen – einem Dokument, das TDF auf Grundlage bewährter Verfahren erstellt hat. Diese haben sich in Dutzenden Projekten bewährt, darunter groß angelegte Vorhaben in Schleswig-Holstein und beim österreichischen Verteidigungsministerium.

Jedes eingehende Dokument sollte sofort in das ODF-Format konvertiert werden, um sämtliche Vorteile des Standardformats zu nutzen. Anschließend sollte es als zweite Kopie im OOXML-Format gespeichert werden, um die Interoperabilität mit proprietären Formaten sicherzustellen. Das dauert nur wenige Sekunden, und Speicherplatz ist sicherlich kein Problem.

Darüber hinaus ist das ODF-Format nicht nur wesentlich robuster als OOXML. In den sehr seltenen Fällen, in denen eine Datei beschädigt ist, ermöglicht es aufgrund der Eigenschaften des Standardformats und der perfekt lesbaren XML-Datei, sämtliche Inhalte wiederherzustellen. Eine beschädigte OOXML-Datei ist dagegen praktisch nicht wiederherstellbar.

Deutschland will offene Formate wie ODF bis 2027 stärker zum Standard in der öffentlichen Verwaltung machen. Was müsste passieren, damit dieses politische Ziel im Alltag ankommt?

Jede Migration zum Standardformat ODF ist möglich, sofern sie strukturiert angegangen wird – mit einem Projekt, das sowohl technische Aspekte, die sich leicht lösen lassen, als auch Aspekte der Umsetzung berücksichtigt, nämlich Prozesse und Nutzer.

Das Problem besteht leider darin, dass der Wechsel von OOXML zu ODF auch einen Wechsel von Microsoft Office oder einem seiner Klone zu LibreOffice erforderlich macht, weil die ODF-Unterstützung in diesen Programmen sehr schlecht ist, wie im jüngsten Artikel unserer Reihe erläutert wurde.

Diese Migration der Anwendungen fügt eine weitere Ebene der Komplexität hinzu. Wäre die ODF-Unterstützung ordentlich statt katastrophal, wäre die Migration des Formats allein kein Problem und würde lediglich die Anpassung einiger OOXML-basierter Prozesse erfordern.

Leider ist die schlechte ODF-Unterstützung Teil der Lock-in-Strategie von Microsoft und den Entwicklern seiner Klone. Wir können daher nicht erwarten, dass sie sich verbessert – selbst angesichts von Entscheidungen wie jener der deutschen Bundesregierung. Diesen Lock-in aufzugeben würde nämlich bedeuten, einen Marktanteil im Wert von fast 30 Milliarden US-Dollar nicht mehr zu schützen, bei einem Nettogewinn von mehr als 90 Prozent dieser Summe.

Warum scheitern ODF-Einführungen trotz klarer politischer Entscheidungen so oft: an der Technik, an Beschaffung, Schulungen und Gewohnheiten – oder an den Machtstrukturen des Softwaremarkts?

Tatsächlich haben sich die meisten Migrationen von Microsoft Office zu LibreOffice nie mit der Frage der Dokumentformate befasst, weil sie nicht von dem Ziel digitaler Souveränität angetrieben waren, sondern ausschließlich von den Softwarekosten. Deshalb haben Organisationen fast immer das OOXML-Format beibehalten.

Erst in den vergangenen Jahren hat die stärkere Fokussierung auf digitale Souveränität dazu geführt, dass Organisationen auch eine Migration von OOXML zu ODF in Betracht ziehen. Dies ist im Migrationsprotokoll bereits vorgesehen. Dabei handelt es sich zwar um einen zusätzlichen Schritt, der jedoch kein Problem darstellt.

Frühere gescheiterte Migrationen von proprietärer zu Open-Source-Software waren nie auf technische Probleme zurückzuführen – selbst wenn versucht wurde, sie als technische Probleme darzustellen. Im Fall München wurde beispielsweise das Dokument, das die technischen Probleme auflistete, von HP, einem Microsoft-Partner, erstellt und enthielt Behauptungen, die an Lächerlichkeit grenzten. Ähnliches geschah in Italien bei der Migration der Stadt Pesaro und der Provinz Bozen.

Es wäre außerdem sinnlos, die Tatsache zu ignorieren, dass die Unternehmen, die weltweit – und auch in Europa – am meisten für Lobbyarbeit ausgeben, die Big-Tech-Konzerne sind. Allein auf EU-Ebene belaufen sich ihre Budgets auf Millionen Euro, ganz zu schweigen von den Budgets der einzelnen Länder, die nicht öffentlich bekannt sind. In Brüssel, wo es Daten gibt, kommen auf jedes Mitglied des Europäischen Parlaments mehr als zwei Lobbyisten. Es ist ein ungleicher Kampf zwischen Open-Source-Software und proprietärer Software.

Machen Cloud-Dienste und KI-Werkzeuge offene Formate weniger wichtig, weil einzelne Dateien an Bedeutung verlieren – oder wichtiger, weil die Kontrolle über Inhalte und Metadaten schwieriger wird?

Dokumente bleiben Dokumente, auch in der Cloud und bei der Nutzung von KI-Werkzeugen. Was die meisten Menschen nicht erkennen, ist, dass sich das Dokument im Laufe der Jahre von einem einfachen Blatt Papier zu einer ausführbaren Datei entwickelt hat. Diese enthält die Anweisungen, die eine Software benötigt, um den Inhalt der Datei auf dem Bildschirm darzustellen. Sie ist daher nicht mehr so „unschuldig“ wie ihre gedruckte Version – jenes einfache Blatt Papier, aus dem sie hervorgegangen ist.

Deshalb ist das Format von Dokumenten wichtiger denn je. Der Unterschied zwischen einem standardisierten, offenen Format und einem proprietären Format ist vergleichbar mit dem Unterschied zwischen Open-Source-Software und proprietärer Software. Bei Dokumenten betrifft dieser Unterschied die Verwaltung der Inhalte: Beim Standardformat ist sie transparent dokumentiert, beim proprietären Format dagegen verschleiert dokumentiert und verwendet Verweise, die nur dem Autor bekannt sind – nämlich Microsoft.

Um eine leicht verständliche Parallele zu ziehen: Es ist, als läge der Schlüssel zu unserer Haustür in den Händen einer externen Instanz, die entscheiden kann, ob und wann wir unser eigenes Zuhause betreten dürfen. Bei einem Standardformat bleibt der Schlüssel immer in den Händen des Eigentümers.

Gibt es aus Ihrer Sicht einen allgemein akzeptierten Kriterienkatalog dafür, wann ein Format wirklich offen ist – oder bewertet die TDF Formate nach eigenen Maßstäben?

Es gibt mehrere Kriterien dafür, wann ein Format wirklich offen ist, auch wenn eine einheitliche Definition fehlt. Im TDF-Blog haben wir deshalb eine Definition veröffentlicht, die wir bei TDF verwenden.

Ihre Frage hat jedoch das Problem der fehlenden einheitlichen Definition deutlich gemacht. Deshalb werde ich auf der kommenden LibreOffice-Konferenz in Pordenone einen Vortrag halten, in dem ich gemeinsame Kriterien für eine solche Definition vorschlage. Mit diesem Thema beschäftige ich mich bereits, denn das Fehlen einer einheitlichen Definition sorgt auf dem Markt für einige Verwirrung.

Wenn eine Verwaltung morgen beginnen wollte: Was wäre die zentrale erste Maßnahme, die Sie unabhängig von Softwarepolitik und Lobbydruck empfehlen würden?

Für öffentliche Verwaltungen gibt es meines Erachtens ein zentrales Problem zu lösen, das in unserem Blogbeitrag „What is Digital Sovereignty?“ beschrieben wird: sicherzustellen, dass nichts Wesentliches verloren gehen kann.

Das entscheidende Wort ist dabei „wesentlich“. Eine Institution muss nicht selbst Eigentümerin der Cloud sein. Sie muss aber sicher sein, dass ihre Daten nicht ebenfalls verschwinden, wenn ein Anbieter morgen vom Markt verschwindet. Sie muss proprietäre Werkzeuge nicht verbieten. Sie muss jedoch gewährleisten, dass das, was sie diesen Werkzeugen anvertraut – ihre Akten, Verträge und Bürgerdaten –, auch für andere als den Anbieter, der das Werkzeug verkauft hat, lesbar, übertragbar und rekonstruierbar bleibt.

Souveränität bedeutet nicht, eine Mauer um den eigenen Besitz zu errichten. Sie ist eine Garantie dafür, aus einer Abhängigkeit aussteigen zu können.

Um dieses Ziel zu erreichen, kann die technische Entscheidung im Kern nur eine sein: Technologien und Werkzeuge zu wählen, die nicht von einem einzigen Unternehmen kontrolliert werden – es sei denn, sie sind vollständig Open Source. Natürlich kann diese Entscheidung angesichts der Entwicklungen der vergangenen Jahrzehnte äußerst schwierig und herausfordernd sein.

Es gibt öffentliche Verwaltungen, deren Infrastruktur auf Lösungen verschiedener Anbieter beruht, und andere, deren Infrastruktur von einem einzigen Anbieter abhängt. Erstere setzen in der Regel bereits zumindest teilweise auf Open Source, während Letztere meist ausschließlich proprietäre Software nutzen.

Der Weg zur digitalen Souveränität ist schwierig, weil dieses Konzept über zu viele Jahre hinweg ignoriert wurde. Es ist ironisch, dass heute alle über digitale Souveränität sprechen, während dieselben Akteure früher die Forderungen von Open-Source-Befürwortern ignoriert haben. Wir verwendeten damals zwar nicht den Begriff „digitale Souveränität“, vertraten aber bereits dasselbe Konzept.

Wenn Sie Nutzern und Organisationen nur eine einzige Regel für den langfristigen Umgang mit wichtigen Dokumenten geben könnten: Welche wäre das?

Die Regel ist sehr einfach: „aktive“ Dokumente – also solche, die bearbeitet werden müssen – sollten im ODF-Format verwaltet werden. „Historische“ Dokumente – also solche mit Referenzinformationen, die nicht verändert werden dürfen – sollten im PDF-Format verwaltet werden. Natürlich ist es auch möglich, alle Dokumente im ODF-Format zu speichern.

Herr Vignoli, vielen Dank für die Antworten!

Das Interview wurde auf Englisch geführt. Das Original findet sich hier.

(fo)

Die JSON-Bibliothek System.Text.Json beherrscht nun den JSON Patch-Standard nach RFC 6902. JSON Patch ist ein standardisiertes Format, um Änderungen an JSON-Dokumenten in Form einer Sequenz von Operationen auszudrücken. Jede Operation spezifiziert dabei den Typ der Änderung (add, remove, replace, move, copy oder test) sowie den Pfad innerhalb des JSON-Dokuments, auf den sich die Modifikation bezieht.

Durch diese strukturierte Beschreibung lassen sich inkrementelle Änderungen effizient übertragen, ohne das gesamte Dokument erneut austauschen zu müssen. Insbesondere in RESTful Web-APIs ist JSON Patch ein etabliertes Mittel, um partielle Updates über HTTP-PATCH zu implementieren.

Ein wesentliches Merkmal von JSON Patch ist die strikte Definition der Pfadangaben über JSON Pointer (RFC 6901), siehe Beispiel in folgender Tabelle. Dadurch werden Änderungen eindeutig und positionsgenau adressiert. JSON Patch eignet sich auch für komplexe Datenmodelle mit tiefen Verschachtelungen oder Arrays.

Der Vorteil von JSON Patch zeigt sich insbesondere bei großen Objekten und eingeschränkter Bandbreite, da nur inkrementelle Änderungen übertragen werden. Bei sehr kleinen Datenstrukturen kann der Mehraufwand für das Erzeugen und Verarbeiten eines Patch-Dokuments größer sein als der Gewinn gegenüber einem vollständigen Update.

Bisher musste man für JSON Patch die ältere Community-Bibliothek Newtonsoft.Json einsetzen. Nun geht es auch mit der neueren Microsoft-Bibliothek System.Text.Json.

Für JSON Patch mit System.Text.Json gibt es eine Erweiterung für System.Text.Json in Form des neuen NuGet-Pakets Microsoft.AspNetCore.JsonPatch.SystemTextJson, das erstmalig zusammen mit .NET 10.0 Preview 4 erschienen ist.

Trotz des „AspNetCore“ im Namen funktioniert dieses Zusatzpaket auch außerhalb von ASP.NET Core.

Microsoft verspricht in der neuen Implementierung „eine verbesserte Leistung und weniger Speichernutzung im Vergleich zu der existierenden Implementierung in Newtonsoft.Json“ in Verbindung mit einem ähnlichen Design wie bei Newtonsoft.Json, einschließlich der Aktualisierung eingebetteter Objekte und Arrays. Bisher nicht verfügbar ist JSON Patch für dynamische Objekte, weil Newtonsoft.Json dafür Reflection einsetzt. System.Text.Json soll aber auch mit dem NativeAOT-Compiler funktionieren.

Leider funktioniert das neue JSON-Patch-Paket nicht in Verbindung mit dem NativeAOT-Compiler des modernen .NET, sondern nur mit dem Just-in-Time-Compiler.

Im NuGet-Paket Microsoft.AspNetCore.JsonPatch.SystemTextJson gibt es eine Klasse Microsoft.AspNetCore.JsonPatch.SystemTextJson.JsonPatchDocument mit einer Methode ApplyTo(obj), die eine JSON-Patch-Operation auf das übergebene Objekt anwendet. Vor dem Anwenden von ApplyTo() lädt man das JSON-Patch-Dokument via JsonSerializer.Deserialize>() in eine Instanz von JsonPatchDocument.

ApplyTo() erwartet im zweiten Parameter vom Typ Action eine Methode, die als Parameter Objekte vom Typ JsonPatchError entgegennimmt. Als JsonPatchError signalisiert ApplyTo() fehlerhafte Operationsnamen, fehlerhafte Pfade und fehlgeschlagene Test-Operationen. Wenn bei einer oder mehreren Operationen ein Fehler auftritt, werden die übrigen fehlerfreien Operationen dennoch verarbeitet.

Folgender Code zeigt ein Beispiel für eine Objekthierarchie:

public class Person
 {
  public string FirstName { get; set; }
  public string LastName { get; set; }
  public string PrivateWebsite { get; set; }
  public string CompanyWebsite { get; set; }
  public string PrivateEmail { get; set; }
  public string OfficeEmail { get; set; }
  public List PhoneNumbers { get; set; } = new();
  public Address Address { get; set; }
 }
 
 public class Address
 {
  public string Street { get; set; }
  public string City { get; set; }
  public string State { get; set; }
  public string ZipCode { get; set; }
 }
 
 public enum PhoneNumberType
 {
  Mobile,
  Home,
  Work,
  Other
 }
 
 public class PhoneNumber
 {
  public string? Number { get; set; }
  public PhoneNumberType Type { get; set; }
 }

Der folgende Codeausschnitt verändert die Objekthierarchie mit JSON Patch:

public void JSONPatchDemo()
 {
  CUI.Demo();

  // Originalobjekt
  var person = new Person
  {
   FirstName = "Holger",
   LastName = "Schwichtenberg",
   PrivateEmail = "buero@IT-Visions.de",
   PrivateWebsite = "www.dotnet-doktor.de",
   CompanyWebsite = "www.IT-Visions.de",
   PhoneNumbers = [new PhoneNumber() { Number = "0201 649590-0", Type = PhoneNumberType.Work }],
   Address = new Address
   {
    Street = "Fahrenberg 40b",
    City = "Essen",
    State = "NRW"
   }
  };

  CUI.H2("Ausgabe des Objekts in seinem alten Zustand");
  CUI.Print(ITVisions.ObjectDumper.Dump(person));

  #region ------------------- Beispiel 1: Anwenden eines JSON-Patch-Dokuments auf ein Objekt
  // JSON-Patch-Dokument: Erlaubte Operationen nach RFC 6902 sind: "add", "remove", "replace", "move", "copy" und "test"
  string jsonPatch = """
[
    { "op": "test", "path": "/FirstName", "value": "Holger" },
    { "op": "test", "path": "/LastName", "value": "Schwichtenberg" },
    { "op": "replace", "path": "/FirstName", "value": "Dr. Holger" },
    { "op": "move", "from": "/PrivateEmail", "path": "/OfficeEmail" },
    { "op": "remove", "path": "/PrivateWebsite" },
    { "op": "add", "path": "/Address/ZipCode", "value": "45257" },
    { "op": "add", "path": "/PhoneNumbers/-", "value": { "Number": "0201 649590-40" } }
]
""";

  // JSON-Patch-Dokument laden
  JsonPatchDocument patchDoc = JsonSerializer.Deserialize>(jsonPatch);

  // JSON-Patch-Dokument anwenden auf das Person-Objekt mit ApplyTo()
  patchDoc!.ApplyTo(person, patchError => CUI.PrintError(patchError.ErrorMessage));

  CUI.H2("Ausgabe des Objekts in seinem neuen Zustand");
  CUI.Print(ITVisions.ObjectDumper.Dump(person));
#endregion
}

Alternativ kann man das Objekt auch als JSON ausgeben. Das habe ich im obigen Listing bewusst ausgelassen, damit nicht der Eindruck entsteht, man müsse das Objekt als JSON weiterverwenden. Folgender Code zeigt die Ausgabe als JSON:

// Ausgabe des Resultats
var serializerOptions = new JsonSerializerOptions()
  {
   IndentSize = 1, WriteIndented=true, IncludeFields = true,
  };
 
Console.WriteLine(JsonSerializer.Serialize(person, serializerOptions));

(rme)