← Back to context

Comment by arh68

12 years ago

Hmm, that's not the impression I got. I don't think they're arguing you should use multiple encodings willy nilly. Rather, they're avoiding the limit of exactly 1 encoding for every input (maximum flexibility in the spec).

Of course, in real-world implementations, the encoder and the decoder will have a shared view of what should be in a CBOR data item. For example, an agreed-to format might be "the item is an array whose first value is a UTF-8 string, second value is an integer, and subsequent values are zero or more floating-point numbers" or "the item is a map that has byte strings for keys and contains at least one pair whose key is 0xab01".

7 is 7 whether it's uint_8 or uint_32, right?

Also, there's actually a much more relevant section later on in the spec (just got to p18):

   For constrained
   applications, where there is a choice between representing a specific
   number as an integer and as a decimal fraction or bigfloat (such as
   when the exponent is small and non-negative), there is a quality-of-
   implementation expectation that the integer representation is used
   directly.