ASN.1 while complex has really seems to be a step up from those (even if older) in terms of terseness (as binary encoding) and generality.
Yes, but that comes from the telecom world. Hence thanks to NIH, that wheel must be reinvented.
From XML to JSON to CBOR
31–40 of 106 posts
Re: From XML to JSON to CBOR
#32Feels like a CBOR ad to me. I agree that most techs are familiar with XML and JSON, but calling CBOR a "pivotal data format" is a stretch compared to Protobuf, Parquet, Avro, Cap'n Proto, and many others: https://en.m.wikipedia.org/wiki/Comparison_of_data-serializa...
CBOR is just a standard data format. Why would it need an ad? What are they selling here?
A lot of people (myself included) are working on tools and protocols that interoperate via CBOR. Nobody is selling CBOR itself, but I for one have a vested interest in promoting CBOR adoption (which makes it sound nefarious but in reality I just think it's a neat format, when you add canonicalization).
CBOR isn't special here, similar incentives could apply to just about any format - but JSON for example is already so ubiquitous that nobody needs to promote it.
Re: From XML to JSON to CBOR
#33The article reads like a semi-slop with its numerous lists and overly long explanations of obvious things, such as how XML came to be.
Re: From XML to JSON to CBOR
#34CBOR has always seemed to me like the most promising data format for efficient data transfer. Somewhat weird how little use it has.
AWS is beginning to support it, starting with certain data-heavy APIs: https://aws.amazon.com/about-aws/whats-new/2025/07/amazon-cl...
Re: From XML to JSON to CBOR
#35How different is CBOR compared to BSON? Both seem to be binary json-like representations. Edit: BSON seems to contain more data types than JSON, and as such it is more complex, whereas CBOR doesn't add to JSON's existing structure.
I think parsing BSON is simpler than parsing JSON, BSON has additional types but the top level is always a document. Whereas the following are all valid JSON:
- `null`
- `"hello"`
- `[1,2,NaN]`
Additionally, BSON will just tell you what the type of a field is. JSON requires inferring it.
Re: From XML to JSON to CBOR
#36Obligatory https://xkcd.com/927/
Re: From XML to JSON to CBOR
#37The only mention I can see in this document of compression is
> Significantly smaller than JSON without complex compression
Although compression of JSON could be considered complex, it's also extremely simple in that it's widely used and usually performed in a distinct step - often transparently to a user. Gzip, and increasingly zstd are widely used.
I'd be interested to see a comparison between compressed JSON and CBOR, I'm quite surprised that this hasn't been included.
Re: From XML to JSON to CBOR
#38CBOR is when you need option for very small code size. If you can always use compression, CBOR provides no significant data size improvement over JSON. With small code size it beats also BSON, EBML and others.
Or compute. Compression isn't free, especially on power constrained devices. At scale power and compute also have real cost implications. Most data centers have long been using binary encoding formats such as protobuf to save on compute and network bandwidth. cbor is nice because it's self describing so you can still understand it without a schema, which is a nice property people like about json.
Re: From XML to JSON to CBOR
#39Previously:
CBOR – Concise Binary Object Representation - https://news.ycombinator.com/item?id=20603378 - Aug 2019 (71 comments)
Begrudgingly Choosing CBOR over MessagePack - https://news.ycombinator.com/item?id=43229259 - Mar 2025 (78 comments)
Re: From XML to JSON to CBOR
#40Love or hate JSON, the beauty and utility stem from the fact that you have only the fundamental datatypes as a requirement, and that's it.
Structured data that, by nesting, pleases the human eye, reduced to the max in a key-value fashion, pure minimalism.
And while you have to write type converters all the time for datetime, BLOBs etc., these converters are the real reasons why JSON is so useful: every OS or framework provides the heavy lifting for it.
So any elaborated new silver bullet would require solving the converter/mapper problem, which it can't.
And you can complain or explain with JSON: "Comments not a feature?! WTF!" - Add a field with the key "comment"
Some smart guys went the extra mile and nevertheless demanded more, because wouldn't it be nice to have some sort of "strict JSON"? JSON schema was born.
And here you can visibly experience the inner conflict of "on the one hand" vs "on the other hand". Applying schemas to JSON is a good cause and reasonable, but guess what happens to JSON? It looks like unreadable bloat, which means XML.
Extensibility is fine, basic operations appeal to both demands, simple and sophisticated, and don't impose the sophistication on you just for a simple 3-field exchange about dog food preferences.