3 ms·
JSON isn't under-specified, you can tell if something's valid JSON just based on the rules here: http://www.json.org/json-en.html http://www.json.org/json-en.ht
by Diggsey 5y ago
JSON isn't under-specified, you can tell if something's valid JSON just based on the rules here: http://www.json.org/json-en.html http://www.json.org/json-en.html. The mapping of the JSON data model to the data models found in various languages is what's ambiguous. Which is not impacted by curl supporting JSON in the slightest:
- The `--json` option only adds a content-type header, it doesn't alter the transmitted data at all.
- The `--jp` option has a bespoke format that's not part of the JSON spec, and which doesn't actually depend on a specific data model, it's just string manipulation.
- gumby 5y agoSee a detailed reply to a parallel comment. Also, —jp is actually generating a JSON.
- Diggsey 5y agoNumbers are the main thing I assumed you were talking about: the JSON spec is clear though, numbers can be arbitrarily long. The problem is not with the JSON spec, the problem is when you are converting from one data model to another. Any program which claims to perfectly round-trip the JSON data-model should support arbitrarily long numbers, there's no ambiguity in the spec about that. If you are only parsing JSON as a means to encode your own data-model, then there's no obligation to support arbitrary precision, but users should not expect to be able to round-trip arbitrary JSON data. AFAICT, `--jp` doesn't do anything which would affect the length of supported numbers, even though it's generating JSON.