Zusammenfassung

  • JSON Type Definition prüft eine Instanz gegen einen absichtlich begrenzten Strukturvertrag; Annahme belegt Form, nicht Wahrheit oder Befugnis.
  • Acht exklusive Formen, lokale Regeln für unbekannte Felder und zwei Fehlerzeiger vermindern stillschweigende Auslegungen zwischen Implementierungen.
  • Absenderprüfung, Autorisierung, Fachregeln, Aktualität, Persistenz und Ergebnisnachweis beginnen erst hinter dem Schema-Gate.

Ein Ereignis trägt den richtigen Typ, eine Zeichenkette als Kennung und einen formal gültigen Zeitstempel. Es kann trotzdem von einem Unbefugten stammen, nach Widerruf wiederholt worden sein oder eine Handlung beschreiben, die nie stattfand. Der Validator sieht die gemeinsame Struktur dieser Fälle. Ihre unterschiedliche Geschichte sieht er nicht.

Genau dafür ist JSON Type Definition in RFC 8927 gebaut. JTD beschreibt verbreitete JSON-Formen, erleichtert Codegenerierung und vereinheitlicht Fehlerorte. Die Sprache will nicht jede denkbare Geschäftsregel ausdrücken. Ihre geringe Ausdrucksmacht ist eine Governance-Entscheidung zugunsten reproduzierbarer Implementierung.

Acht Formen statt versteckter Rangfolge

JTD kennt acht gegenseitig ausschließende Formen: empty, ref, type, enum, elements, properties, values und discriminator. Die leere Form akzeptiert alles. Referenzen greifen auf Definitionen der Wurzel zurück. Properties beschreibt einen Datensatz, values ein Wörterbuch, discriminator eine markierte Variante.

Ein Schema kann nicht zwei Formen mischen und die Bibliothek über Vorrang entscheiden lassen. Definitionen stehen nur an der Wurzel. Eine Discriminator-Verzweigung darf das Tag nicht als anderen Typ neu festlegen. Die gemeinsame Bedeutung hängt dadurch weniger von Auswertungsreihenfolge und Verschachtelung ab.

RFC 8927 stammt aus dem Independent Stream und ist Experimental. Es trägt weder IETF-Konsens noch Standards-Track-Status. Erfolg soll durch mehrere unabhängige Implementierungen sichtbar werden, die JTD tatsächlich für Informationsaustausch einsetzen. Die Publikation selbst ist kein Laufzeitbeleg.

CDDL kann reichere Regeln ausdrücken und beschreibt im RFC sogar die Syntax von JTD. Dass JTD sich nicht selbst beschreiben kann, ist bewusst: Ein kleiner gemeinsamer Kern ersetzt nicht die lokal benötigte Vollständigkeit.

Das leere Schema besteht immer

Die empty-Form akzeptiert jede JSON-Instanz und erzeugt nie einen Fehler. „JTD bestanden“ hat daher ohne Schemaidentität kaum Aussagekraft. Ein belastbarer Beleg bindet Nachrichten-Hash, Schema-Hash und -Version, Validator-Build, Modus und Erweiterungsprofil.

Auch metadata bleibt begrenzt. Es kann Dokumentation oder Hinweise für Generatoren und lokale Werkzeuge tragen. Andere Parteien müssen es nicht verstehen. Soll metadata die Prüfung verändern, entsteht gemeinsames Verhalten erst durch eine Vereinbarung außerhalb von JTD. Ein amtlich klingender Schlüssel ist noch keine portable Regel.

In Heng Lus Realitätsschichten beschreibt das Ergebnis eine ausgeführte Beziehung zwischen Nachricht und Vertrag. Es erzeugt weder Identität noch den behaupteten Zustand.

Offenheit gilt nicht automatisch nach innen

Die properties-Form trennt Pflichtfelder und optionale Felder; unbekannte Namen werden standardmäßig abgelehnt. additionalProperties:true öffnet nur das Objekt, in dem die Option steht. Unterobjekte erben sie nicht.

So kann ein äußerer Umschlag zukünftige Routingdaten zulassen, während eine eingebettete Zahlungsanweisung geschlossen bleibt. Ein globaler „permissive“-Schalter einer Bibliothek würde diese Risikogrenze vernichten. Telemetrie muss die konkrete Objektebene und die dort wirksame Regel festhalten.

Vorwärtskompatibilität ist eine lokale Zukunftsentscheidung. Das Ignorieren eines neuen Feldes kann Evolution ermöglichen oder eine entscheidende Anweisung unterschlagen. Der Empfänger, der das Risiko trägt, entscheidet pro Grenze.

Zwei Zeiger geben keinen Auftrag

Ein Standardfehler enthält instancePath zum abgelehnten Wert und schemaPath zur ablehnenden Regel. Beide verwenden JSON Pointer. Die Paarung macht den Zusammenstoß von Daten und Vertrag nachvollziehbar.

Die Reihenfolge mehrerer Fehler ist nicht festgelegt. Das erste Element ist weder sicher Ursache noch höchste Priorität. Ein Pointer lokalisiert nur; er bestimmt keinen Verantwortlichen und erlaubt keine automatische Korrektur. Dafür braucht es eine eigene, überprüfbare Richtlinie.

Formal richtige Zeit bleibt eine Behauptung

JTD unterscheidet boolesche Werte, Strings, Gleitkommazahlen, vorzeichenbehaftete und vorzeichenlose Ganzzahlen von 8 bis 32 Bit sowie Zeitstempel. Der Zeitstempel folgt RFC 3339 in der durch Atom verengten Form. Die Grammatik beweist weder eine vertrauenswürdige Uhr noch ein eingetretenes Ereignis.

int64 und uint64 fehlen absichtlich, weil JSON-Ökosysteme den gesamten Bereich nicht zuverlässig exakt erhalten. I-JSON benennt einen kleineren interoperablen Bereich. JTD lässt lieber einen attraktiven Typ weg, als eine falsche Präzisionsgarantie zu vermitteln.

Auch ein discriminator wählt nur eine Variante. Das Tag account_deleted kann eine ID erzwingen, aber keine Löschung beweisen. Authentifizierung, Befugnis, Annahme, dauerhafte Speicherung und spätere Rücklese sind getrennte Belege.

Der Prüfer braucht ein Arbeitsbudget

Referenzen können Zyklen bilden. RFC 8927 empfiehlt bei nutzergegebenen Schemas Erkennung und Abbruch, weil naive Rekursion zur Denial-of-Service-Fläche wird. RFC 8259 erlaubt Grenzen für Eingabegröße, Tiefe und Zahlenpräzision.

Betrieb braucht Budgets für Bytes, Tiefe, Referenzauflösung, Fehlerzahl und Zeit. Außerdem muss klar sein, ob ein Schema vertrauenswürdiges Artefakt, Mandanteneingabe oder entfernte Abhängigkeit ist. Syntaktisch korrektes JSON ist nicht automatisch sichere Arbeit.

Quellen

  1. RFC 8927 — JSON Type Definition
  2. RFC 8259 — JSON Data Interchange Format
  3. RFC 7493 — I-JSON Message Format
  4. RFC 6901 — JSON Pointer
  5. RFC 3339 — Datum und Zeit im Internet
  6. RFC 4287 — Atom Syndication Format
  7. RFC 8610 — Concise Data Definition Language
  8. Heng Lu — Running-Code Primacy
  9. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  10. Heng Lu — On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile