Qui ci sono due idee distinte.
La prima idea è che il formato potrebbe avere tipi. XML no; XDR e bencoding fanno. Come evidentemente sei a conoscenza, lo schema XML aggiunge tipi di dati a XML; questo è evidentemente qualcosa che molte persone hanno trovato carente in XML. Inoltre, se hai digitato i dati, se stai utilizzando un formato non tipizzato, a un certo punto, stai mappando tra forme tipizzate e non tipizzate, e viceversa, nel qual caso stai essenzialmente imponendo il tuo sistema di tipi. Si potrebbe anche avere un sistema di tipi nel formato per iniziare.
La seconda idea è che il formato potrebbe incorporare tipi nei dati. XML non può, perché non ha tipi. XDR no, fa bencoding. Ci sono molti altri esempi su entrambi i lati. Il compromesso è semplice: i formati che non incorporano i tipi possono essere più compatti, ma i formati che fanno possono fare un lavoro migliore per individuare gli errori. Un errore molto comune è un cambio di formato: si scrivono alcuni dati nella versione N del formato e lo si legge con la versione N + M del formato; più informazioni sul tipo e sulla struttura che incorpori, maggiori sono le possibilità che hai di rilevare questo piuttosto che leggere la spazzatura. I dati con tipi incorporati possono anche essere elaborati senza conoscere la sua struttura (ad esempio, si traducono dati bencoded in JSON senza sapere nulla di ciò che era nei dati, non è possibile farlo con XDR), ma sospetto che sia raramente utile in real vita.
Quindi, è un compromesso. Se il formato è per l'interscambio di dati tra macchine di un cluster, dove tutti eseguiranno lo stesso codice, i vantaggi di integrità dei tipi incorporati sembrano in gran parte irrilevanti. Se è per l'interscambio di dati tra diverse società, o per l'archiviazione a lungo termine di dati da qualche sistema, il vantaggio di integrità potrebbe essere molto prezioso.