From XML to JSON to CBOR

Original Article ↗ Hacker News Discussion ↗

Scope of the article and examples

  • Several readers note this chapter is just one slice of a larger “CBOR book,” but still criticize it for omitting a direct CBOR byte-level example alongside the XML/JSON ones.
  • Others point out that later sections (“Putting it together”) do show JSON, diagnostic CBOR, and hex, but agree this is not obvious from the linked page.
  • Technical readers also miss an explicit description of CBOR’s encoding schema in this introductory section.

CBOR vs BSON, JSON, MessagePack, Cap’n Proto

  • BSON is seen as “binary JSON with more types”; some say its parsing is simpler because the top-level is always a document and field types are explicit.
  • CBOR is described as similar in spirit but with:
    • Custom semantic tags and an IANA registry for extended types.
    • More precise primitive distinctions (ints, bytes vs strings).
  • There is a substantial subthread arguing CBOR is essentially a fork/variant of MessagePack with altered tags and an IETF spec, versus a counter-view that CBOR rethinks the model (major/minor types, indefinite-length items).
  • Cap’n Proto is praised for efficiency, especially for zero-copy/shared-memory and its RPC system, but noted to require schemas and be less comparable to self-describing CBOR.
  • Some argue schema-based formats (protobuf, Cap’n Proto) are fine because most real systems map unstructured JSON into typed classes anyway.

Binary formats vs text and DIY formats

  • One camp advocates writing custom TLV-style binary formats: simple, fast, compact, and educational.
  • Critics argue this adds bespoke maintenance burden, complicates team onboarding, and rarely matters unless profiling shows serialization as a hot path.
  • CBOR is positioned by some as a good “off-the-shelf” compromise: compact, self-describing, small codec footprint, especially for constrained devices.

Adoption, “ad” feel, and compression

  • Some feel the text reads like a CBOR promotion and overstates its “pivotal” status compared to more widely known formats.
  • Others say promoting a spec is natural when many tools/protocols depend on it.
  • Several note that compressed JSON (gzip/zstd) is ubiquitous and would significantly narrow size advantages; they’re surprised the article doesn’t compare CBOR vs compressed JSON.

JSON, ASN.1, and other alternatives

  • JSON is praised for minimal core types and ubiquity, but criticized for numeric edge cases, NaN, implementation divergence, and lack of binary type.
  • JSON Schema is seen as valuable but making JSON feel “XML-like” when heavily used.
  • ASN.1/DER/BER/PER are defended as powerful and general but hampered by poor tooling in many languages and high perceived complexity; some prefer DER and even define custom textual forms that map to it.