For example, the number 10 is encoded as 0x10.
As an example, that is fantastically opaque. It tells me nothing sensible at all, there could just be a magic look-up table that you're assumed to know, for all I know. I can't draw any conclusions that lead me to believe that CBOR is "simple" from that example.
Then, it contradicts the above in the table, where it claims:
The one thing that Flynn seems to be missing is tests. Right now I run tests by parsing the examples from the RFC, so I consider the test suite pretty complete (for the features I have implemented). Glad this got posted since perhaps my test suite could be useful for Flynn.
The main problem it currently faces is that the encoding/decoding support for half-width floats is currently wrong, but so long as you avoid half-width floats it works perfectly.
Eventually I want to add support for encoding indefinite lists by way of one of the streaming libraries like conduit or pipes, but before I do that I need to refactor to the code to break the Binary instances out from the types.
Not sure why yet another binary encoding method is needed (per editor comments on the original ietf mailing list).