====== Internationale Grundregeln ====== **Gemeinsame Regeln für alle B2Base-Schemata** Der gemeinsame Kern legt Datenbedeutungen fest. Nationale Regeln und besondere Verfahren werden ausdrücklich ergänzt. [[schemes:scheme|Bibliothek]] · [[:guidelines|Integration]] ===== Schrift, Namen und Sprache ===== 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. [[https://www.w3.org/International/questions/qa-personal-names|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. [[https://www.rfc-editor.org/rfc/rfc5646.html|RFC 5646]] ===== Länder, Regionen und Adressen ===== 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. [[https://www.iso.org/iso-3166-country-codes.html|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. [[https://www.w3.org/International/questions/qa-address-formats|W3C: internationale Adressen]] ===== Kennungen, Codes und Referenzen ===== * **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. [[https://json-schema.org/understanding-json-schema/structuring|JSON Schema: Referenzen]] ===== Datum, Zeit und Genauigkeit ===== * **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. [[https://www.rfc-editor.org/rfc/rfc3339.html|RFC 3339]] ===== Zahlen, Geld und Einheiten ===== 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. [[https://www.six-group.com/en/products-services/financial-information/market-reference-data/data-standards.html|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. [[https://unece.org/code-list-recommendations|UN/CEFACT: Einheiten]] ===== Fehlend, leer und unbekannt ===== 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. ===== Kern, Profil und Erweiterung ===== 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. ===== Was die Prüfung nicht belegt ===== 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. [[https://json-schema.org/draft/2020-12/json-schema-validation|JSON Schema: Validierung]]