Re: [apps-discuss] Concise Binary Object Representation (CBOR)

[Carsten Bormann <[e-mail]>]

> The only types I have found a need for in my JSON schema are:
> 
> Integer
> Float 
> String (UTF8)
> DateTime   (As RFC 3339 format string)
> Binary (as base64 encoded string)
> List (X)  - JSON List

CBOR is a pretty good match then (we also have a map/dictionary/table/JSON object).
(There is never a need to base-64 encode anything in CBOR.)

> Since most of the proposals are of the form <type> <data> where <type> and we only have 7 fundamental types it is quite easy to make the type octet combine the type and length information. So if the integer fits in 2 bytes then just use 2 bytes and mark the length in the type octet, the number 256 could be represented as:
> 
> X2 01 00

Yep.
(CBOR has a slightly different encoding of the first byte to be able to encode the number right there if it fits).

> I would use twos compliment for all values and so a 64 bit unsigned integer could potentially have 9 octets but that would be a rare event.

CBOR uses two different encoding types for unsigned and negative numbers.  See Figure 2 for an easy way to convert signed integers to that.

> A side benefit to this approach is that big numbers are easily supported.

CBOR also has a representation for big (> 64-bit) numbers (based on the byte string).

> Representing floats is a lot harder than the specs I have written seem to understand. In particular the main reason I would want a binary format for JSON is that it is NOT possible to round trip floats from decimal format to binary without special care.

Representing floats is rather easy -- IEEE 754 is well-documented.  So CBOR uses the three main binary floating point formats from that (Half, Single, Double).
If you do need (negative) base-10 exponents, we have a special Decimal fraction (inspired by YANG and EXI), trying not to use decimal mantissae.

> So the main reason for using a binary JSON is going to be not introducing the errors, possibly cumulative errors that round tripping from decimal to binary introduces.

That is one good reason (not the main one I'm interested in).

> So we do need to have 32 bit and 64 it floats.

Strictly, that is not needed, as every 32-bit float can be easily converted into a 64-bit float.
But the inverse (going down from 64 to 32 to 16, and checking whether that is lossless) is also easy.

Grüße, Carsten