5 ms·

XML shines at the intersection of structured documents and structured data. For pure data you can use JSON or s-expresssions but this does not work very well wi

XML shines at the intersection of structured documents and structured data. For pure data you can use JSON or s-expresssions but this does not work very well with more document-orinted data. There is a reason frontend frameworks use HTML templates or JSX even though js supports JSON natively.

crabbone 4y ago
Why do people advocate for JSON so much? It's simple, I can see that, but it also got most of its stuff wrong. If I had a liberty to choose a format in which I want to receive data, JSON would've been very much down on the list. These are just the problems that actually bit me in my professional use of JSON, not some theoretical possibilities: * No bounds on how big integers may be, subsequently, an ambiguity about what to do if the number is bigger than what would be considered a typical integer size for the platform: should it be interpreted as a float or as an integer? In my case, I had ids coming from a database that used 128-bit to represent them and the client side silently converted them to floats, but, on the way back, converted them to integers again, which resulted in rare collisions and lost data. * No defined semantics for repeated keys in hash-tables. I used a library that tried to stream JSON in SAS-like way, but the authors didn't realize that duplicate keys are a possibility. Again, this caused subtle and hard to identify data integrity issues. * Unnecessary null value. For some languages null and false are the same thing (and I prefer it that way too), but converting data back and forth between JSON and language-native data would sometimes produce inconsistent results, and, again, caused a once-in-a-year case of data integrity issue. * Mandatory Unicode string encoding. Caused problems with DICOMs from East Asia. DICOMs have some special encodings that can have characters not representable in Unicode. You can guess that I've learned it the hard way too. And there isn't a way to transfer raw data (of course, you can Base64 encode it etc. but that's not a function of the format, the parties need to agree on format extension in order to understand that).
- rwmj 4y ago
  JSON sucks as a format. You forgot to mention the lack of optional commas, and the need to quote keys. However 'jq' is absolutely great, and that unfortunately is why we used it for some command line tools that had to output structured data.
  - bazoom42 4y ago
    “As a format” depends on what you use it for. No comments and simple syntax is great for an interchange format but a drawback for a configuration file format.
    - butlerm 4y ago
      The problem is json is not a simple format. In one major respect it is more difficult to generate than XML. The inability to handle commas as terminators rather than separators is a disaster that immensely complicates generating arbitrary json. That aspect only appears to be useful with trusted documents and dangerous eval style processing in Javascript in the first place. Of course it originated as JavaScript Object Notation, but it has significant downsides even as a replacement for a restricted dialect of XML. It is (regrettably) both difficult to read and difficult to generate by comparison. The absence of support for comments is a problem for ubiquitous use for configuration files as well.
      - bazoom42 4y ago
        > The inability to handle commas as terminators rather than separators is a disaster that immensely complicates generating arbitrary json. This is a bit over the top. At worst you need a flag to special-case the first item.
- bazoom42 4y ago
  XML does not support non-unicode characters either. For an interchange format this is a good thing, not a drawback.
- fluoridation 4y ago
  >And there isn't a way to transfer raw data (of course, you can Base64 encode it etc. but that's not a function of the format, the parties need to agree on format extension in order to understand that). That seems like an odd complaint. The particular structure of the JSON is also not part of JSON itself, and thus parties need to agree on that too. Why are some implicit agreements okay while others aren't?
  - crabbone 4y ago
    I think, what you mean by structure of JSON is the structure of individual documents encoded in JSON, not JSON format itself. In the case of JSON format itself no agreement is necessary. As long as both programs implement the format definition, they are good to go and don't need to be aware of the existence of the other. This is evidenced by, eg. ability of text editors to edit JSON files w/o needing any knowledge about the producer of the file. Compare this to, for example, Protobuf, where once you get the binary Protobuf message, you absolutely have to know what program generated it and how, otherwise you will not be able to read it. You cannot make a generic Protobuf editor the same way you can make a generic JSON editor.
- planede 4y ago
  > For some languages null and false are the same thing (and I prefer it that way too) Ugh, It's hard to pin the blame on JSON for this one. Seriously? My other gripe is languages/libraries that can't distinguish between missing key and present key with null value. It's more subtle, but these are also different.
  - crabbone 4y ago
    There's absolutely no need for two nulls / nils. But the story of JSON is that it was created by extracting part of JavaScript... so, that part was kept because it was part of JavaScript, which has never been known for making good language choices. So, bad choices made once just stuck with this format. I don't think the author gave it much thought really.
    - bazoom42 4y ago
      It is an implementation detail in C that 0, false, and NULL has the same representation. Other languages are differet, e.g SQL.
- acdha 4y ago
  Isn't your complain about integers the reverse of your complaint about nulls? I think it's reasonable to want better semantics for precisely specifying common types (I'd add dates to that list) but it seems like in both cases what you want is a way to say exactly what your source and destination types should be rather than having silent lossy conversion.
  - crabbone 4y ago
    No. Two different nulls are unnecessary. Integers are just poorly defined (but are, actually quite handy to have, I'm not against integers). I wouldn't care if there was only one type of integers, or if there were hundreds as long as the definition doesn't leave it up to the program writing the data to define the meaning of the data. It's very similar to the problem of single-byte text encoding, where programs wrote data somehow, and afterwards had to guess how did they write it.
    - acdha 4y ago
      > Two different nulls are unnecessary false and null have different semantic meanings, do you mean “null“ and “undefined”?
      - crabbone 4y ago
        False and null are the same thing. Undefined may be a property of a variable (what in Prolog-like languages would be called "variable" or "non-ground"). But, in this capacity it wouldn't be a value, it would be a property, similar to how in OO language you could say "it's a big class" (meaning it's a class that has more than five methods specializing on it), but you wouldn't start modeling your problem domain by creating BigClass class and then inheriting from it any time you want a class with more than five methods.

crabbone 4y ago

Why do people advocate for JSON so much? It's simple, I can see that, but it also got most of its stuff wrong. If I had a liberty to choose a format in which I want to receive data, JSON would've been very much down on the list. These are just the problems that actually bit me in my professional use of JSON, not some theoretical possibilities: * No bounds on how big integers may be, subsequently, an ambiguity about what to do if the number is bigger than what would be considered a typical integer size for the platform: should it be interpreted as a float or as an integer? In my case, I had ids coming from a database that used 128-bit to represent them and the client side silently converted them to floats, but, on the way back, converted them to integers again, which resulted in rare collisions and lost data. * No defined semantics for repeated keys in hash-tables. I used a library that tried to stream JSON in SAS-like way, but the authors didn't realize that duplicate keys are a possibility. Again, this caused subtle and hard to identify data integrity issues. * Unnecessary null value. For some languages null and false are the same thing (and I prefer it that way too), but converting data back and forth between JSON and language-native data would sometimes produce inconsistent results, and, again, caused a once-in-a-year case of data integrity issue. * Mandatory Unicode string encoding. Caused problems with DICOMs from East Asia. DICOMs have some special encodings that can have characters not representable in Unicode. You can guess that I've learned it the hard way too. And there isn't a way to transfer raw data (of course, you can Base64 encode it etc. but that's not a function of the format, the parties need to agree on format extension in order to understand that).

rwmj 4y ago
JSON sucks as a format. You forgot to mention the lack of optional commas, and the need to quote keys. However 'jq' is absolutely great, and that unfortunately is why we used it for some command line tools that had to output structured data.
- bazoom42 4y ago
  “As a format” depends on what you use it for. No comments and simple syntax is great for an interchange format but a drawback for a configuration file format.
  - butlerm 4y ago
    The problem is json is not a simple format. In one major respect it is more difficult to generate than XML. The inability to handle commas as terminators rather than separators is a disaster that immensely complicates generating arbitrary json. That aspect only appears to be useful with trusted documents and dangerous eval style processing in Javascript in the first place. Of course it originated as JavaScript Object Notation, but it has significant downsides even as a replacement for a restricted dialect of XML. It is (regrettably) both difficult to read and difficult to generate by comparison. The absence of support for comments is a problem for ubiquitous use for configuration files as well.
    - bazoom42 4y ago
      > The inability to handle commas as terminators rather than separators is a disaster that immensely complicates generating arbitrary json. This is a bit over the top. At worst you need a flag to special-case the first item.
bazoom42 4y ago
XML does not support non-unicode characters either. For an interchange format this is a good thing, not a drawback.
fluoridation 4y ago
>And there isn't a way to transfer raw data (of course, you can Base64 encode it etc. but that's not a function of the format, the parties need to agree on format extension in order to understand that). That seems like an odd complaint. The particular structure of the JSON is also not part of JSON itself, and thus parties need to agree on that too. Why are some implicit agreements okay while others aren't?
- crabbone 4y ago
  I think, what you mean by structure of JSON is the structure of individual documents encoded in JSON, not JSON format itself. In the case of JSON format itself no agreement is necessary. As long as both programs implement the format definition, they are good to go and don't need to be aware of the existence of the other. This is evidenced by, eg. ability of text editors to edit JSON files w/o needing any knowledge about the producer of the file. Compare this to, for example, Protobuf, where once you get the binary Protobuf message, you absolutely have to know what program generated it and how, otherwise you will not be able to read it. You cannot make a generic Protobuf editor the same way you can make a generic JSON editor.
planede 4y ago
> For some languages null and false are the same thing (and I prefer it that way too) Ugh, It's hard to pin the blame on JSON for this one. Seriously? My other gripe is languages/libraries that can't distinguish between missing key and present key with null value. It's more subtle, but these are also different.
- crabbone 4y ago
  There's absolutely no need for two nulls / nils. But the story of JSON is that it was created by extracting part of JavaScript... so, that part was kept because it was part of JavaScript, which has never been known for making good language choices. So, bad choices made once just stuck with this format. I don't think the author gave it much thought really.
  - bazoom42 4y ago
    It is an implementation detail in C that 0, false, and NULL has the same representation. Other languages are differet, e.g SQL.
acdha 4y ago
Isn't your complain about integers the reverse of your complaint about nulls? I think it's reasonable to want better semantics for precisely specifying common types (I'd add dates to that list) but it seems like in both cases what you want is a way to say exactly what your source and destination types should be rather than having silent lossy conversion.
- crabbone 4y ago
  No. Two different nulls are unnecessary. Integers are just poorly defined (but are, actually quite handy to have, I'm not against integers). I wouldn't care if there was only one type of integers, or if there were hundreds as long as the definition doesn't leave it up to the program writing the data to define the meaning of the data. It's very similar to the problem of single-byte text encoding, where programs wrote data somehow, and afterwards had to guess how did they write it.
  - acdha 4y ago
    > Two different nulls are unnecessary false and null have different semantic meanings, do you mean “null“ and “undefined”?
    - crabbone 4y ago
      False and null are the same thing. Undefined may be a property of a variable (what in Prolog-like languages would be called "variable" or "non-ground"). But, in this capacity it wouldn't be a value, it would be a property, similar to how in OO language you could say "it's a big class" (meaning it's a class that has more than five methods specializing on it), but you wouldn't start modeling your problem domain by creating BigClass class and then inheriting from it any time you want a class with more than five methods.