1.1. Objectives (Ziele)

1.1. Objectives (Ziele)

Die Ziele von CBOR, grob in abnehmender Reihenfolge der Wichtigkeit, sind:

1. Die Darstellung muss in der Lage sein, die meisten gängigen Datenformate, die in Internetstandards verwendet werden, eindeutig zu kodieren.

   • Sie muss einen vernünftigen Satz grundlegender Datentypen und Strukturen unter Verwendung binärer Kodierung darstellen. "Vernünftig" ist hier weitgehend von den Fähigkeiten von JSON beeinflusst, mit der Hauptergänzung binärer Byte-Strings. Die unterstützten Strukturen sind auf Arrays und Bäume beschränkt; Schleifen und gitterartige Graphen werden nicht unterstützt.

   • Es besteht keine Anforderung, dass alle Datenformate eindeutig kodiert werden; das heißt, es ist akzeptabel, dass die Zahl "7" auf mehrere verschiedene Arten kodiert werden kann.

2. Der Code für einen Encoder oder Decoder muss kompakt sein können, um Systeme mit sehr begrenztem Speicher, Prozessorleistung und Befehlssätzen zu unterstützen.

   • Ein Encoder und ein Decoder müssen mit einer sehr geringen Menge an Code implementierbar sein (zum Beispiel in Klasse-1-Constraint-Knoten, wie in [CNN-TERMS] definiert).

   • Das Format sollte zeitgenössische Maschinendarstellungen von Daten verwenden (zum Beispiel ohne binär-zu-dezimal-Konvertierung).

3. Daten müssen ohne Schemabeschreibung dekodiert werden können.

   • Ähnlich wie JSON sollten kodierte Daten selbstbeschreibend sein, so dass ein generischer Decoder geschrieben werden kann.

4. Die Serialisierung muss vernünftig kompakt sein, aber Datenkompaktheit ist sekundär zur Code-Kompaktheit für Encoder und Decoder.

   • "Vernünftig" ist hier durch JSON als obere Grenze in der Größe und durch Implementierungskomplexität, die eine untere Grenze aufrechterhält, begrenzt. Die Verwendung allgemeiner Komprimierungsschemata oder umfangreicher Bit-Manipulation verletzt die Komplexitätsziele.

5. Das Format muss sowohl auf Constraint-Knoten als auch auf Anwendungen mit hohem Volumen anwendbar sein.

   • Dies bedeutet, dass es bei CPU-Nutzung sowohl für Kodierung als auch für Dekodierung vernünftig sparsam sein muss. Dies ist sowohl für Constraint-Knoten als auch für potenzielle Verwendung in Anwendungen mit einem sehr hohen Datenvolumen relevant.

6. Das Format muss alle JSON-Datentypen für die Konvertierung von und nach JSON unterstützen.

   • Es muss ein vernünftiges Maß an Konvertierung unterstützen, solange die dargestellten Daten innerhalb der Fähigkeiten von JSON liegen. Es muss möglich sein, ein unidirektionales Mapping zu JSON für alle Datentypen zu definieren.

7. Das Format muss erweiterbar sein, und die erweiterten Daten müssen von früheren Decodern dekodierbar sein.

   • Das Format ist für jahrzehntelange Nutzung ausgelegt.

   • Das Format muss eine Form der Erweiterbarkeit unterstützen, die Rückfallmöglichkeiten erlaubt, so dass ein Decoder, der eine Erweiterung nicht versteht, die Nachricht dennoch dekodieren kann.

   • Das Format muss in Zukunft durch spätere IETF-Standards erweiterbar sein.