2. CBOR Data Models (Modelli di Dati CBOR)

CBOR è esplicito riguardo al suo modello di dati generico (Generic Data Model), che definisce l'insieme di tutti gli elementi di dati che possono essere rappresentati in CBOR. Il suo modello di dati generico di base è estensibile tramite la registrazione di "valori semplici" (Simple Values) e tag. Le applicazioni possono quindi creare un sottoinsieme del modello di dati generico esteso risultante per costruire i loro modelli di dati specifici (Specific Data Models).

All'interno di ambienti che possono rappresentare gli elementi di dati nel modello di dati generico, possono essere implementati encoder e decoder CBOR generici (il che di solito comporta la definizione di tipi di dati di implementazione aggiuntivi per quegli elementi di dati che non hanno già una rappresentazione naturale nell'ambiente). La capacità di fornire encoder e decoder generici è un obiettivo di progettazione esplicito di CBOR; tuttavia, molte applicazioni forniranno i propri encoder e/o decoder specifici dell'applicazione.

Nel modello di dati generico di base (non esteso) definito nella Sezione 3, un elemento di dati è uno dei seguenti:

• un intero nell'intervallo -2^(64)..2^(64)-1 incluso

• un valore semplice, identificato da un numero tra 0 e 255, ma distinto da quel numero stesso

• un valore in virgola mobile, distinto da un intero, dell'insieme rappresentabile da IEEE 754 binary64 (inclusi i non-finiti) [IEEE754]

• una sequenza di zero o più byte ("stringa di byte", Byte String)

• una sequenza di zero o più punti di codice Unicode ("stringa di testo", Text String)

• una sequenza di zero o più elementi di dati ("array", Array)

• una mappatura (funzione matematica) da zero o più elementi di dati ("chiavi", Keys) ciascuno a un elemento di dati ("valori", Values), ("mappa", Map)

• un elemento di dati etichettato ("tag", Tag), comprendente un numero di tag (un intero nell'intervallo 0..2^(64)-1) e il contenuto del tag (un elemento di dati)

Si noti che i valori interi e in virgola mobile sono distinti in questo modello, anche se hanno lo stesso valore numerico.

Si noti inoltre che le varianti di serializzazione non sono visibili a livello di modello di dati generico. Questa assenza deliberata di visibilità include il numero di byte del valore in virgola mobile codificato. Include anche la scelta della codifica per un "argomento" (argument) (vedere Sezione 3) come la codifica per un intero, la codifica per la lunghezza di una stringa di testo o byte, la codifica per il numero di elementi in un array o coppie in una mappa, o la codifica per un numero di tag.

2.1. Extended Generic Data Models (Modelli di Dati Generici Estesi)

Questo modello di dati generico di base è stato esteso in questo documento dalla registrazione di un numero di valori semplici e numeri di tag, come:

• "false", "true", "null" e "undefined" (valori semplici identificati da 20..23, Sezione 3.3)

• valori interi e in virgola mobile con un intervallo e una precisione maggiori di quanto sopra (numeri di tag da 2 a 5, Sezione 3.4)

• tipi di dati dell'applicazione come un punto nel tempo o una stringa di data/ora definita in RFC 3339 (numeri di tag 1 e 0, Sezione 3.4)

Elementi aggiuntivi del modello di dati generico esteso possono essere (e sono stati) definiti tramite i registri IANA creati per CBOR. Anche se tale estensione è sconosciuta a un encoder o decoder generico, gli elementi di dati che utilizzano tale estensione possono essere passati da o verso l'applicazione rappresentandoli all'interfaccia dell'applicazione all'interno del modello di dati generico di base, cioè come valori semplici generici o tag generici.

In altre parole, il modello di dati generico di base è stabile come definito in questo documento, mentre il modello di dati generico esteso si espande tramite la registrazione di nuovi valori semplici o numeri di tag, ma non si riduce mai.

Mentre esiste una forte aspettativa che gli encoder e i decoder generici possano rappresentare "false", "true" e "null" ("undefined" è intenzionalmente omesso) nella forma appropriata per il loro ambiente di programmazione, l'implementazione delle estensioni del modello di dati create dai tag è veramente opzionale e una questione di qualità dell'implementazione.

2.2. Specific Data Models (Modelli di Dati Specifici)

Il modello di dati specifico per un protocollo basato su CBOR di solito prende un sottoinsieme del modello di dati generico esteso e assegna semantica dell'applicazione agli elementi di dati all'interno di questo sottoinsieme e dei suoi componenti. Quando si documentano tali modelli di dati specifici e si specificano i tipi di elementi di dati, è preferibile identificare i tipi con i loro nomi di modello di dati generico ("intero negativo" (Negative Integer), "array" (Array)) invece di riferirsi ad aspetti della loro rappresentazione CBOR ("tipo principale 1" (Major Type 1), "tipo principale 4" (Major Type 4)).

I modelli di dati specifici possono anche specificare l'equivalenza dei valori (inclusi valori di tipi diversi) ai fini delle chiavi della mappa e della libertà dell'encoder. Ad esempio, nel modello di dati generico, una mappa valida PUÒ avere sia "0" che "0.0" come chiavi, e un encoder NON DEVE codificare "0.0" come un intero (tipo principale 0, Sezione 3.1). Tuttavia, se un modello di dati specifico dichiara che le rappresentazioni in virgola mobile e intere dei valori integrali sono equivalenti, l'utilizzo di entrambe le chiavi della mappa "0" e "0.0" in una singola mappa sarebbe considerato duplicati, anche se codificati come tipi principali diversi, e quindi non valido; e un encoder potrebbe codificare i float con valore integrale come interi o viceversa, forse per risparmiare byte codificati.