2. CBOR Data Models (Modèles de Données CBOR)
CBOR est explicite sur son modèle de données générique (Generic Data Model), qui définit l'ensemble de tous les éléments de données qui peuvent être représentés en CBOR. Son modèle de données générique de base est extensible par l'enregistrement de "valeurs simples" (Simple Values) et d'étiquettes (Tags). Les applications peuvent ensuite créer un sous-ensemble du modèle de données générique étendu résultant pour construire leurs modèles de données spécifiques (Specific Data Models).
Dans les environnements qui peuvent représenter les éléments de données dans le modèle de données générique, des encodeurs et décodeurs CBOR génériques peuvent être implémentés (ce qui implique généralement de définir des types de données d'implémentation supplémentaires pour les éléments de données qui n'ont pas encore de représentation naturelle dans l'environnement). La capacité de fournir des encodeurs et décodeurs génériques est un objectif de conception explicite de CBOR; cependant, de nombreuses applications fourniront leurs propres encodeurs et/ou décodeurs spécifiques à l'application.
Dans le modèle de données générique de base (non étendu) défini dans la Section 3, un élément de données est l'un des suivants:
-
un entier dans la plage -2^(64)..2^(64)-1 inclus
-
une valeur simple, identifiée par un nombre entre 0 et 255, mais distincte de ce nombre lui-même
-
une valeur à virgule flottante, distincte d'un entier, de l'ensemble représentable par IEEE 754 binary64 (y compris les non-finis) [IEEE754]
-
une séquence de zéro ou plusieurs octets ("chaîne d'octets", Byte String)
-
une séquence de zéro ou plusieurs points de code Unicode ("chaîne de texte", Text String)
-
une séquence de zéro ou plusieurs éléments de données ("tableau", Array)
-
une application (fonction mathématique) de zéro ou plusieurs éléments de données ("clés", Keys) chacun vers un élément de données ("valeurs", Values), ("carte", Map)
-
un élément de données étiqueté ("étiquette", Tag), comprenant un numéro d'étiquette (un entier dans la plage 0..2^(64)-1) et le contenu de l'étiquette (un élément de données)
Notez que les valeurs entières et à virgule flottante sont distinctes dans ce modèle, même si elles ont la même valeur numérique.
Notez également que les variantes de sérialisation ne sont pas visibles au niveau du modèle de données générique. Cette absence délibérée de visibilité inclut le nombre d'octets de la valeur à virgule flottante encodée. Elle inclut également le choix de l'encodage pour un "argument" (voir Section 3) tel que l'encodage pour un entier, l'encodage pour la longueur d'une chaîne de texte ou d'octets, l'encodage pour le nombre d'éléments dans un tableau ou de paires dans une carte, ou l'encodage pour un numéro d'étiquette.
2.1. Extended Generic Data Models (Modèles de Données Génériques Étendus)
Ce modèle de données générique de base a été étendu dans ce document par l'enregistrement d'un certain nombre de valeurs simples et de numéros d'étiquettes, tels que:
-
"false", "true", "null" et "undefined" (valeurs simples identifiées par 20..23, Section 3.3)
-
valeurs entières et à virgule flottante avec une plage et une précision plus grandes que ce qui précède (numéros d'étiquettes 2 à 5, Section 3.4)
-
types de données d'application tels qu'un point dans le temps ou une chaîne de date/heure définie dans RFC 3339 (numéros d'étiquettes 1 et 0, Section 3.4)
Des éléments supplémentaires du modèle de données générique étendu peuvent être (et ont été) définis via les registres IANA créés pour CBOR. Même si une telle extension est inconnue d'un encodeur ou décodeur générique, les éléments de données utilisant cette extension peuvent être transmis vers ou depuis l'application en les représentant à l'interface d'application dans le modèle de données générique de base, c'est-à-dire en tant que valeurs simples génériques ou étiquettes génériques.
En d'autres termes, le modèle de données générique de base est stable tel que défini dans ce document, tandis que le modèle de données générique étendu s'étend par l'enregistrement de nouvelles valeurs simples ou numéros d'étiquettes, mais ne se réduit jamais.
Bien qu'il existe une forte attente que les encodeurs et décodeurs génériques puissent représenter "false", "true" et "null" ("undefined" est intentionnellement omis) sous la forme appropriée pour leur environnement de programmation, l'implémentation des extensions du modèle de données créées par les étiquettes est vraiment optionnelle et une question de qualité d'implémentation.
2.2. Specific Data Models (Modèles de Données Spécifiques)
Le modèle de données spécifique pour un protocole basé sur CBOR prend généralement un sous-ensemble du modèle de données générique étendu et attribue une sémantique d'application aux éléments de données dans ce sous-ensemble et ses composants. Lors de la documentation de tels modèles de données spécifiques et de la spécification des types d'éléments de données, il est préférable d'identifier les types par leurs noms de modèle de données générique ("entier négatif" (Negative Integer), "tableau" (Array)) au lieu de se référer aux aspects de leur représentation CBOR ("type majeur 1" (Major Type 1), "type majeur 4" (Major Type 4)).
Les modèles de données spécifiques peuvent également spécifier une équivalence de valeur (y compris des valeurs de différents types) pour les besoins des clés de carte et de la liberté d'encodeur. Par exemple, dans le modèle de données générique, une carte valide PEUT avoir à la fois "0" et "0.0" comme clés, et un encodeur NE DOIT PAS encoder "0.0" comme un entier (type majeur 0, Section 3.1). Cependant, si un modèle de données spécifique déclare que les représentations à virgule flottante et entières des valeurs intégrales sont équivalentes, l'utilisation des deux clés de carte "0" et "0.0" dans une seule carte serait considérée comme des doublons, même si elles sont encodées en types majeurs différents, et donc invalide; et un encodeur pourrait encoder des flottants à valeur intégrale comme des entiers ou vice versa, peut-être pour économiser des octets encodés.