JSON wird als UTF-8 gespeichert. Texte dürfen alle Unicode-Schriften enthalten. Originale bleiben erhalten; Umschrift, Übersetzung und Suchnormalisierung sind zusätzliche Darstellungen. Ein Name muss nicht aus Vor- und Nachname bestehen. Die Anzeige folgt dem angegebenen vollständigen Namen, nicht einer für alle Kulturen angenommenen Reihenfolge. W3C: internationale Namen

Sprachen verwenden BCP-47-Tags, etwa de, zh-Hant-TW, sr-Latn oder x-internal. Sprache, Schrift, Wohnland und Staatsangehörigkeit sind unterschiedliche Angaben. Das mitgelieferte Muster für Sprachtags ist eine Prüfung der Grundform; eine vollständige BCP-47-Prüfung einschließlich registrierter Teilcodes benötigt einen passenden Parser. RFC 5646

Länderkennungen verwenden, wo angegeben, ISO 3166-1 Alpha-2 in Großbuchstaben. Das Muster [A-Z]{2} prüft allein die Schreibweise. Zulässige Codes, historische Gültigkeit und gegebenenfalls vereinbarte Erweiterungen müssen aus einer aktuellen beziehungsweise zeitlich passenden Liste stammen. Unbekannt bedeutet nicht automatisch ZZ, staatenlos nicht automatisch ein erfundener Ländercode. ISO 3166

Adresszeilen dürfen in Originalschrift und landesüblicher Reihenfolge übergeben werden. Nicht überall gibt es Straßennamen, Hausnummern oder Postleitzahlen. Geordnete Druckzeilen und strukturierte Suchfelder haben verschiedene Aufgaben. Ein Ländercode sagt noch nichts über die Zustellbarkeit. W3C: internationale Adressen

• Kennung: Wert plus Kennungssystem. Führende Nullen bleiben erhalten. Beispiel: value: „00042“ zusammen mit einer eindeutigen scheme-URI.
• Fachlicher Code: value plus scheme benennt die Bedeutung, label ist nur die lesbare Bezeichnung. Codes aus verschiedenen Systemen nicht stillschweigend gleichsetzen.
• Datensatzverweis: Eine absolute URI oder URN in id, documentRef oder einem entsprechend benannten Feld identifiziert Daten. Die Existenz des Ziels ist separat zu prüfen.
• Schema-Verweis: $ref gehört in ein Schema. In Beispieldaten lädt ein Feld namens $ref keine Person, Adresse oder Datei.

In den Download-Dateien sind wiederverwendete Bausteine unter $defs eingebettet. Somit ist zum Validieren kein Nachladen von Wiki-Seiten nötig. Die $id-Kennung und die tatsächliche lokale Download-Adresse dürfen sich unterscheiden. JSON Schema: Referenzen

• Datum: YYYY-MM-DD bezeichnet ein vollständig bekanntes gregorianisches Kalenderdatum. Kein Offset und keine Uhrzeit ergänzen, wenn fachlich nur ein Datum gemeint ist.
• Zeitpunkt: RFC-3339-Darstellung mit Z oder einem numerischen Offset, etwa 2026-09-08T10:00:00+02:00. Wiederkehrende lokale Termine benötigen zusätzlich eine gesonderte Zeitzonenregel.
• Teilbekanntes Geburtsdatum: Nur Jahr oder Jahr und Monat in birthDatePartial. Nicht den 1. Januar als Ersatz für einen unbekannten Tag verwenden.
• Anderer Kalender: Originalangabe erhalten und Kalender benennen. Eine Umrechnung braucht eine festgelegte Regel.

Die hier eingesetzten Formatprüfer haben Implementierungsgrenzen, etwa bei Schaltsekunden. Anwendungen müssen ihr unterstütztes RFC-3339-Profil vereinbaren. Zeitfolgen wie Ausstellungsdatum vor Ablaufdatum sind zusätzliche fachliche Regeln. RFC 3339

Postleitzahlen, Kontonummern, Dokumentnummern und Registerkennungen sind Text, keine Rechenwerte. Geld und präzise Messwerte werden ebenfalls als Dezimaltext ohne Gruppierungszeichen transportiert; die Währung beziehungsweise Einheit wird separat genannt. Rechenoperationen benötigen eine geeignete Dezimalarithmetik.

Währungen verwenden ISO 4217. Es gilt keine universelle Regel von zwei Nachkommastellen; die Liste des offiziellen Pflegers enthält die jeweiligen Untereinheiten. Zulässige Genauigkeit und Rundung legt zusätzlich das Geschäftsprofil fest. SIX: Währungen und Untereinheiten

Messwerte enthalten unitCode und unitScheme. Für Handelsmaße bietet UN/CEFACT Recommendation 20 eine Referenz. Einheit und Messdefinition sind gemeinsam zu prüfen; Wohnfläche und Grundstücksfläche werden nicht durch dieselbe Quadratmeterangabe gleichbedeutend. UN/CEFACT: Einheiten

Ein optionales Feld wird weggelassen, wenn es nicht erhoben wurde oder nicht anwendbar ist. Das allein unterscheidet diese Gründe nicht; ein Verfahren, das diese Unterscheidung benötigt, ergänzt einen ausdrücklich benannten Status. null, 0, false, „“ und ein fehlendes Feld sind keine austauschbaren Werte.

Ein als Pflicht markierter Text darf nicht leer sein. Eine leere Staatsangehörigkeitsliste bedeutet nur zusammen mit dem ausdrücklichen Status stateless Staatenlosigkeit. Eine leere Liste von Dokumenten beweist nicht, dass keine Dokumente existieren.

Der Kern enthält die ausdrücklich definierten Felder. Unbekannte Kernfelder werden im Austauschschema abgewiesen, damit Schreibfehler nicht unbemerkt bleiben. Wo vorgesehen, kann extensions vereinbarte Zusätze unter absoluten URI-Schlüsseln aufnehmen. Diese Schlüssel benötigen eine eigene Dokumentation; ihre Inhalte werden vom Kern nicht fachlich geprüft.

Ein Länder- oder Branchenprofil darf zusätzliche Anforderungen benennen. Es bekommt eine eigene Schema-ID und Versionsregel. Keinen Feldnamen mit einer anderen Bedeutung wiederverwenden. Bei geschlossenen Objekten lässt sich ein neues Feld nicht einfach durch allOf anfügen: Das Profil muss die erlaubten Eigenschaften vollständig zusammenstellen oder den vorgesehenen Erweiterungsbereich benutzen.

Ein erfolgreicher Schematest prüft Struktur und ausgewählte Formate. Er bestätigt keine Identität, Zustellbarkeit, Bankverbindung, Berechtigung, rechtliche Wirkung oder weltweite Anerkennung eines Dokuments. Formate werden in JSON Schema standardmäßig als Annotationen behandelt; Validatoren müssen für die gewünschte Formatprüfung eingerichtet werden. JSON Schema: Validierung