5 ms·

So if JSON parsers can't agree on what JSON actually is, that isn't a problem?

by dagenix 9y ago

benzoate 9y ago
I consider it more like behaviour outside of the spec is undefined, and some parsers have bugs.
- dagenix 9y ago
  A good spec should define all those corner cases. With Json, it's possible for two bug free libraries to take the same input and produce a different output.
  - arghwhat 9y ago
    Only if the input is invalid JSON.
arghwhat 9y ago
JSON parsers all agree what JSON actually is (except for the brown colored fields in the compat matrix, which are actual JSON compat bugs). JSON parsers may also permit various additional variations which are very explicitly not JSON. This means that they may accept a handcrafted, technically invalid JSON document. However, a JSON encoder may never generate a document containing such "extensions", as this would not be JSON. This concept of having parsers accept more than necessary follows best practices of robustness. As the robustness principle goes: "Be conservative in what you do, be liberal in what you accept from others".
- jacobparker 9y ago
  > As the robustness principle goes [...] "The Harmful Consequences of the Robustness Principle" https://tools.ietf.org/html/draft-thomson-postel-was-wrong-03 https://tools.ietf.org/html/draft-thomson-postel-was-wrong-0...
  - craftyguy 9y ago
    The author advocates adding previously invalid extensions to the spec as they come up, as an alternate way to handle 'robustness'. How would this not rapidly lead to a bloated, buggy, unmaintainable spec?
  - meuk 9y ago
    I want to upvote this so many more times than I'm able to. The principle is even more harmful, because it sounds so logical. If many JSON parser accept your JSON object which is not valid JSON, any new parser that doesn't accept it will be booed as a faulty parser. If your input is not according to spec, throw an error. The sender is wrong. They deserve to know it and need to fix their output.

So if JSON parsers can't agree on what JSON actually is, that isn't a problem?

benzoate 9y ago

I consider it more like behaviour outside of the spec is undefined, and some parsers have bugs.

dagenix 9y ago
A good spec should define all those corner cases. With Json, it's possible for two bug free libraries to take the same input and produce a different output.
- arghwhat 9y ago
  Only if the input is invalid JSON.

arghwhat 9y ago

JSON parsers all agree what JSON actually is (except for the brown colored fields in the compat matrix, which are actual JSON compat bugs). JSON parsers may also permit various additional variations which are very explicitly not JSON. This means that they may accept a handcrafted, technically invalid JSON document. However, a JSON encoder may never generate a document containing such "extensions", as this would not be JSON. This concept of having parsers accept more than necessary follows best practices of robustness. As the robustness principle goes: "Be conservative in what you do, be liberal in what you accept from others".

jacobparker 9y ago
> As the robustness principle goes [...] "The Harmful Consequences of the Robustness Principle" https://tools.ietf.org/html/draft-thomson-postel-was-wrong-03 https://tools.ietf.org/html/draft-thomson-postel-was-wrong-0...
- craftyguy 9y ago
  The author advocates adding previously invalid extensions to the spec as they come up, as an alternate way to handle 'robustness'. How would this not rapidly lead to a bloated, buggy, unmaintainable spec?
- meuk 9y ago
  I want to upvote this so many more times than I'm able to. The principle is even more harmful, because it sounds so logical. If many JSON parser accept your JSON object which is not valid JSON, any new parser that doesn't accept it will be booed as a faulty parser. If your input is not according to spec, throw an error. The sender is wrong. They deserve to know it and need to fix their output.