> Do you mean non-json types? Because the supported types seem pretty straightforward. (besides perhaps supporting null bytes in strings in things like postgres

> Do you mean non-json types? Because the supported types seem pretty straightforward. (besides perhaps supporting null bytes in strings in things like postgresql) What is a "number"? Is it a float? int? short? double? BigDecimal? What about time values? Or dates? Oh, you have to just shove those into strings and hope both sides agree? That's fun. > Care to explain? This has always seemed like one of jsons strengths. The syntax for what is valid is pretty straightforward. One example is the json "spec" on json.org does not allow trailing commas yet many parsers do