2. CBOR Data Models (CBOR-Datenmodelle)

CBOR ist explizit über sein generisches Datenmodell (Generic Data Model), das die Menge aller Datenelemente definiert, die in CBOR dargestellt werden können. Sein grundlegendes generisches Datenmodell ist durch die Registrierung von "einfachen Werten" (Simple Values) und Tags erweiterbar. Anwendungen können dann eine Teilmenge des resultierenden erweiterten generischen Datenmodells erstellen, um ihre spezifischen Datenmodelle (Specific Data Models) zu erstellen.

In Umgebungen, die die Datenelemente im generischen Datenmodell darstellen können, können generische CBOR-Encoder und -Decoder implementiert werden (was normalerweise die Definition zusätzlicher Implementierungsdatentypen für jene Datenelemente umfasst, die noch keine natürliche Darstellung in der Umgebung haben). Die Fähigkeit, generische Encoder und Decoder bereitzustellen, ist ein explizites Designziel von CBOR; viele Anwendungen werden jedoch ihre eigenen anwendungsspezifischen Encoder und/oder Decoder bereitstellen.

Im grundlegenden (nicht erweiterten) generischen Datenmodell, das in Abschnitt 3 definiert ist, ist ein Datenelement eines der folgenden:

• eine Ganzzahl im Bereich -2^(64)..2^(64)-1 einschließlich

• ein einfacher Wert, identifiziert durch eine Zahl zwischen 0 und 255, aber unterschiedlich von dieser Zahl selbst

• ein Gleitkommawert, unterschiedlich von einer Ganzzahl, aus der durch IEEE 754 binary64 darstellbaren Menge (einschließlich nicht-endlicher Werte) [IEEE754]

• eine Sequenz von null oder mehr Bytes ("Byte-Zeichenfolge", Byte String)

• eine Sequenz von null oder mehr Unicode-Codepunkten ("Textzeichenfolge", Text String)

• eine Sequenz von null oder mehr Datenelementen ("Array", Array)

• eine Abbildung (mathematische Funktion) von null oder mehr Datenelementen ("Schlüssel", Keys) jeweils auf ein Datenelement ("Werte", Values), ("Map", Map)

• ein getaggtes Datenelement ("Tag", Tag), bestehend aus einer Tag-Nummer (eine Ganzzahl im Bereich 0..2^(64)-1) und dem Tag-Inhalt (ein Datenelement)

Beachten Sie, dass Ganzzahl- und Gleitkommawerte in diesem Modell unterschiedlich sind, auch wenn sie denselben numerischen Wert haben.

Beachten Sie auch, dass Serialisierungsvarianten auf der Ebene des generischen Datenmodells nicht sichtbar sind. Diese absichtliche Unsichtbarkeit umfasst die Anzahl der Bytes des codierten Gleitkommawerts. Sie umfasst auch die Wahl der Codierung für ein "Argument" (siehe Abschnitt 3) wie die Codierung für eine Ganzzahl, die Codierung für die Länge einer Text- oder Byte-Zeichenfolge, die Codierung für die Anzahl der Elemente in einem Array oder Paare in einer Map oder die Codierung für eine Tag-Nummer.

2.1. Extended Generic Data Models (Erweiterte Generische Datenmodelle)

Dieses grundlegende generische Datenmodell wurde in diesem Dokument durch die Registrierung einer Reihe einfacher Werte und Tag-Nummern erweitert, wie zum Beispiel:

• "false", "true", "null" und "undefined" (einfache Werte, identifiziert durch 20..23, Abschnitt 3.3)

• Ganzzahl- und Gleitkommawerte mit größerem Bereich und Präzision als oben (Tag-Nummern 2 bis 5, Abschnitt 3.4)

• Anwendungsdatentypen wie ein Zeitpunkt oder eine Datums-/Zeitzeichenfolge, die in RFC 3339 definiert sind (Tag-Nummern 1 und 0, Abschnitt 3.4)

Zusätzliche Elemente des erweiterten generischen Datenmodells können (und wurden) über die für CBOR erstellten IANA-Register definiert werden. Selbst wenn eine solche Erweiterung einem generischen Encoder oder Decoder unbekannt ist, können Datenelemente, die diese Erweiterung verwenden, an die Anwendung oder von der Anwendung weitergegeben werden, indem sie an der Anwendungsschnittstelle innerhalb des grundlegenden generischen Datenmodells dargestellt werden, d.h. als generische einfache Werte oder generische Tags.

Mit anderen Worten, das grundlegende generische Datenmodell ist stabil, wie in diesem Dokument definiert, während sich das erweiterte generische Datenmodell durch die Registrierung neuer einfacher Werte oder Tag-Nummern erweitert, aber niemals schrumpft.

Während es eine starke Erwartung gibt, dass generische Encoder und Decoder "false", "true" und "null" ("undefined" wird absichtlich weggelassen) in der für ihre Programmierumgebung geeigneten Form darstellen können, ist die Implementierung der durch Tags erstellten Datenmodellerweiterungen wirklich optional und eine Frage der Implementierungsqualität.

2.2. Specific Data Models (Spezifische Datenmodelle)

Das spezifische Datenmodell für ein CBOR-basiertes Protokoll nimmt normalerweise eine Teilmenge des erweiterten generischen Datenmodells und weist den Datenelementen innerhalb dieser Teilmenge und ihren Komponenten Anwendungssemantik zu. Bei der Dokumentation solcher spezifischen Datenmodelle und der Spezifikation der Typen von Datenelementen ist es vorzuziehen, die Typen durch ihre generischen Datenmodellnamen ("negative Ganzzahl" (Negative Integer), "Array" (Array)) zu identifizieren, anstatt sich auf Aspekte ihrer CBOR-Darstellung ("Haupttyp 1" (Major Type 1), "Haupttyp 4" (Major Type 4)) zu beziehen.

Spezifische Datenmodelle können auch Wertäquivalenz (einschließlich Werte verschiedener Typen) für die Zwecke von Map-Schlüsseln und Encoder-Freiheit spezifizieren. Zum Beispiel KANN in dem generischen Datenmodell eine gültige Map sowohl "0" als auch "0.0" als Schlüssel haben, und ein Encoder DARF NICHT "0.0" als Ganzzahl codieren (Haupttyp 0, Abschnitt 3.1). Wenn jedoch ein spezifisches Datenmodell erklärt, dass Gleitkomma- und Ganzzahldarstellungen von integralen Werten äquivalent sind, würde die Verwendung beider Map-Schlüssel "0" und "0.0" in einer einzelnen Map als Duplikate betrachtet werden, auch wenn sie als verschiedene Haupttypen codiert sind, und daher ungültig; und ein Encoder könnte integral bewertete Gleitkommazahlen als Ganzzahlen oder umgekehrt codieren, möglicherweise um codierte Bytes zu sparen.