5 ms·

> There aren't vast numbers of different JSON formats. Independent variations I have seen: * Trailing commas allowed or not * Comments allowed or not * Multip

> There aren't vast numbers of different JSON formats. Independent variations I have seen: * Trailing commas allowed or not * Comments allowed or not * Multiple kinds of date serialization conventions * Divergent conventions about distinguishing floating point types from integers * Duplicated key names tolerated or not * Different string escaping policies, such as, but not limited to "\n" vs "\x0a" There are bazillions of JSON variations.

thayne 2y ago
> Trailing commas allowed or not The json spec does not allow commas. Although there are jsom supersets that do. > Comments allowed or not The json spec does not allow comments. Although there are jsom supersets that do. > Multiple kinds of date serialization conventions Json spec doesn't say anything about dates. That is dependent on your application schema. > Divergent conventions about distinguishing floating point types from integers This is largely due to divergent ways different programming languages handle numbers. I won't say jsom handles this the best, but any file format used across multiple languages will run into problems with differences in how numbers are represented. At least there is a well defined difference between a number and a string, unlike csv. > Duplicated key names tolerated or not According to the spec, they are tolerated, although the semantics of such keys is implementation defined. > Different string escaping policies, such as, but not limited to "\n" vs "\x0a" Both of those are interpreted as the same thing, at least according to the spec. That is an implementation detail of the serializer, not a different language.
- recursive 2y ago
  And CSV parsers and serializers compliant with RFC 4180 are similarly reliable.
  - thayne 2y ago
    But many, perhaps most, parsers and serializers for CSV are not compliant with RFC 4180. RFC 4180 is not an official standard. The text of the RFC itself states: > This memo provides information for the Internet community. It does > not specify an Internet standard of any kind. CSVs existed long before that RFC was written, and it is more a description of CSVs that are somewhat portable, not a definitive specification.
  - IanCal 2y ago
    That RFC doesn't even support utf8. It is, and accepts it is, codifing best practices rather than defining an authoritative standard.
IanCal 2y ago
There are always many, but in comparison to csv I've received almost no differences. Json issues were rare but csv issues it was common to have a brand new issue per client. Typically the big difference is there are different parsers that are less tolerant of in spec values. Clickhouse had a more restrictive parser, and recently I've dealt with matrix. Maybe I've been lucky for json and unlucky for csv.

thayne 2y ago

> Trailing commas allowed or not The json spec does not allow commas. Although there are jsom supersets that do. > Comments allowed or not The json spec does not allow comments. Although there are jsom supersets that do. > Multiple kinds of date serialization conventions Json spec doesn't say anything about dates. That is dependent on your application schema. > Divergent conventions about distinguishing floating point types from integers This is largely due to divergent ways different programming languages handle numbers. I won't say jsom handles this the best, but any file format used across multiple languages will run into problems with differences in how numbers are represented. At least there is a well defined difference between a number and a string, unlike csv. > Duplicated key names tolerated or not According to the spec, they are tolerated, although the semantics of such keys is implementation defined. > Different string escaping policies, such as, but not limited to "\n" vs "\x0a" Both of those are interpreted as the same thing, at least according to the spec. That is an implementation detail of the serializer, not a different language.

recursive 2y ago
And CSV parsers and serializers compliant with RFC 4180 are similarly reliable.
- thayne 2y ago
  But many, perhaps most, parsers and serializers for CSV are not compliant with RFC 4180. RFC 4180 is not an official standard. The text of the RFC itself states: > This memo provides information for the Internet community. It does > not specify an Internet standard of any kind. CSVs existed long before that RFC was written, and it is more a description of CSVs that are somewhat portable, not a definitive specification.
- IanCal 2y ago
  That RFC doesn't even support utf8. It is, and accepts it is, codifing best practices rather than defining an authoritative standard.

IanCal 2y ago

There are always many, but in comparison to csv I've received almost no differences. Json issues were rare but csv issues it was common to have a brand new issue per client. Typically the big difference is there are different parsers that are less tolerant of in spec values. Clickhouse had a more restrictive parser, and recently I've dealt with matrix. Maybe I've been lucky for json and unlucky for csv.