Fix editorial and substantive issues in CBOR section.

This PR reworks the CBOR section in the same way the JSON and JSON-LD sections were reworked. The changes are largely editorial or non-substantive, but there is one change that is substantive.

There were rules regarding preserving "unknown data types"... except that there is no such thing in the ADM... we either know about the data type, or we can't represent it in the ADM. It is impossible for an "unknown data type" to exist in the ADM... all data types are known, or they're not representable. Similarly, it is impossible for a CBOR consumer to consume data with an unknown data type and preserve it in the ADM... because there is nowhere to put it (because the data type is unknown). You can't convert it to a string (which is what was specified) because the production rules would spit it out as a string (it wasn't a string when it was consumed -- so you'd get data corruption). I removed that normative statement because it was unimplementable.

There is also a rule that I'm concerned about, and that we handwave over, but is required if we want to preserve the CBOR Canonical Rules requirement. There is a requirement in CBOR Canonical Rules that you must specify whether you preserve CBOR Tags or not. If you don't, you can't round-trip from CBOR to some internal representation and back out to CBOR. The problem is that the ADM has no way to preserve the incoming CBOR Tags. So, the current consumption rules say: "CBOR tags MUST be retained for CBOR production". The production rules say "All CBOR tags MUST be retained regardless of whether they are optional." The statements are testable because you can provide a CBOR document with tags and fail if the same tags don't get added when you produce CBOR. In other words, if you can't round-trip, you don't have a conforming CBOR implementation... but honestly, this is a really high bar and it's not clear what we're getting out of it. The same is true for the CBOR Canonical Rules -- they're not easy to do exhaustive tests on... but I retained them because @jonnycrunch was so intent on having them in the spec.

So, keep an eye out for those items as you're reviewing.

/cc @jonnycrunch

Preview | Diff

w3c / did-core

Fix editorial and substantive issues in CBOR section. #663