3 ms·
I deleted my snarky comment because I want to be more serious. You never know when you hack something quick if it may become a future standard for trillions of
by SavantIdiot 5y ago
I deleted my snarky comment because I want to be more serious.
You never know when you hack something quick if it may become a future standard for trillions of handshakes!
JSON looks so clean and tidy on that business card, but when you look at both RFCs you realize: ZOMG there is a lot of stuff that needs to be thought out!!
There are some purists in this thread who claim it is the parsers' fault. I can almost get behind that, but not 100% because you really do need to be more clear about several things (different types of numbers, different character sets, minimum requirements -and- maximum requirements...)
I agree with OP that not including implicit version numbers was an oversight: it looks ugly, but if you're not going to put in all the thought in at the start, at least make a version number required so you can ignore mistakes.
Let this document be a lesson to anyone who writes a data schema/grammar that eventually replaces JSON.
- admax88qqq 5y agoI dunno man, serialization in general is fraught with peril. At least the JSON grammar is short and simple. I can't believe people in here are genuinely recommending XML as an alternative. Try standardizinh XML in a 14 page RFC. Yes some things need to be though out, but I can sit down and read the JSON RFC start to finish easily.
- SavantIdiot 5y ago> I dunno man, serialization in general is fraught with peril. I completely agree. And I'm certain I'm using JSON in an unsafe way... somewhere. :)
- Ginden 5y agoAnd many people choose to ignore that number parsing issues can happen in XML too.