5 ms·

> JSON is simpler to read and write, and it’s less prone to bugs. Less prone to bugs? How's that?

skybrian 9y ago
RSS is sometimes ambiguous and there's a lot of variation. It can be hard to parse correctly. Not sure about Atom, though.
- CharlesW 9y ago
  > RSS is sometimes ambiguous and there's a lot of variation. I've written a reasonably-popular podcast feed validator, and I don't understand either of these criticisms. Mind elaborating?
  - bastawhiz 9y ago
    > I've written a reasonably-popular podcast feed validator Mind sharing?
    - dsp1234 9y ago
      https://podba.se/validate/ https://podba.se/validate/
      - bastawhiz 9y ago
        Nice, very cool! Definitely an improvement on the trash legacy validators out there.
    - deleted 9y ago
      [deleted]
  - skybrian 9y ago
    Since you've done it recently, I'm sure you know more than I do; I suspect my knowledge of it is obsolete.
  - nmcfarl 9y ago
    Not the parent but my company consumed a bit of RSS starting in 2005 (and with the amounts declining to 0 through the years). Over time we've been fed feeds with character encodings not matching what the web server nor the XML declared. Use of undeclared XML namespaces, or quite popular: using elements from other namespaces, without namespaces or declarations -- just shove some nice iTunes things or Atom things into the RSS. Also invalid XML -- just skipping the closing tags was popular. These feeds were from paying customers, and we were not the primary consumers - so when we complained they would generally point to someone else who was consuming it without problem. Sometimes we'd point them at a validator, if they were a small enough customer -- but mostly we just kept working on our in house RSS feed reader that could read tag soup. Things did massively improve over time, and that by the end we were getting _mainly_ reasonably valid RSS.
  - thousande 9y ago
    Not been writing XML parsers, but I remember Nick Bradbury the creator of the FeedDemon fame wrote about it a lot 'back in the days', * https://nickbradbury.com/2006/09/21/fixing_funky_fe_1/ https://nickbradbury.com/2006/09/21/fixing_funky_fe_1/ * http://nick.typepad.com/blog/2004/01/feeddemon_and_w.html http://nick.typepad.com/blog/2004/01/feeddemon_and_w.html * https://en.wikipedia.org/wiki/FeedDemon https://en.wikipedia.org/wiki/FeedDemon
jonknee 9y ago
Probably this part: > simpler to read and write
- halloij 9y ago
  If you're writing these things by hand, you're probably doing something wrong...
  - jonknee 9y ago
    JSON is also easier for computers to read and write...
    - halloij 9y ago
      XML generators and parsers have been in use for a decade+. Pretty sure most of the bugs have been found and fixed by now. It's just reinventing the wheel because the new generation don't want to use the same tools the previous generation did. The time and effort spent doing this is quite ridiculous. (FWIW, I hate XML, JSON is far better. But there's more important things to work on).
      - ergothus 9y ago
        > Pretty sure most of the bugs have been found and fixed by now. Given the complexity and what I've seen from some other long established codebases, I don't share your confidence. > It's just reinventing the wheel because the new generation don't want to use the same tools the previous generation did. You can disagree with the decisions involved (as you did with the XML vulnerability argument), but the fact that those arguments exist means they AREN'T doing it just because they don't want to use the same tools the previous generation did - they have different reasons that you think aren't good reasons. Saying it as you did comes across as smug and dismissive, which is not an effective way of convincing your audience that you've taken arguments into account when making your decision.
      - deleted 9y ago
        [deleted]
crdoconnor 9y ago
JSON parsers have a much smaller 'feature surface' meaning that there are fewer nooks and crannies for bugs to live in. One example of a bug that often festered in XML parsers: https://en.wikipedia.org/wiki/Billion_laughs https://en.wikipedia.org/wiki/Billion_laughs (there is no JSON equivalent of this) The generalized theory, for those interested : https://en.wikipedia.org/wiki/Rule_of_least_power https://en.wikipedia.org/wiki/Rule_of_least_power
- kr0 9y ago
  What from I grok the guy requesting JSON-LD wants this functionality
- zokier 9y ago
  While I'd agree that parsing JSON is much easier than XML, it is still not completely trivial as demonstrated by this article: http://seriot.ch/parsing_json.php http://seriot.ch/parsing_json.php
StevePerkins 9y ago
I couldn't help but take a dismissive stance toward the rest of the page after reading the first paragraph.
bastawhiz 9y ago
Consider XML entity bombs. You need to explicitly tell your XML parser not to follow the spec to prevent malicious sources of XML from crashing your application. XML also has a lot of room for syntax errors, with many types of tokens and escape rules. JSON, by comparison, does not.
- jjawssd 9y ago
  > XML also has a lot of room for syntax errors, with many types of tokens and escape rules. JSON, by comparison, does not. Parsing JSON is a minefield. Yellow and light blue boxes highlight the worst situations for applications using the specified parser. Take a look at how a bunch of parsers perform with various payloads: http://seriot.ch/json/pruned_results.png http://seriot.ch/json/pruned_results.png "JSON is the de facto standard when it comes to (un)serialising and exchanging data in web and mobile programming. But how well do you really know JSON? We'll read the specifications and write test cases together. We'll test common JSON libraries against our test cases. I'll show that JSON is not the easy, idealised format as many do believe. Indeed, I did not find two libraries that exhibit the very same behaviour. Moreover, I found that edge cases and maliciously crafted payloads can cause bugs, crashes and denial of services, mainly because JSON libraries rely on specifications that have evolved over time and that left many details loosely specified or not specified at all." More details available at: http://seriot.ch/parsing_json.php http://seriot.ch/parsing_json.php
  - floatboth 9y ago
    None of these issues are as bad as the XML ones. You generally don't need "defusedjson" like you need https://pypi.python.org/pypi/defusedxml https://pypi.python.org/pypi/defusedxml <!DOCTYPE external [ <!ENTITY ee SYSTEM "file:///etc/ssh/ssh_host_ed25519_key"> ]> <root>&ee;</root>
  - bastawhiz 9y ago
    Parser correctness is irrelevant when you're talking about the ability to be written with few syntax errors. For instance, JSON has one type of string with one set of string escape rules. XML has element names, attribute names, attribute values, text nodes, CDATA content, RCDATA content, and more. And almost all of them have different rules for what they can contain and how they can be used. By comparison, XML is orders of magnitude more complex than JSON.

RSS is sometimes ambiguous and there's a lot of variation. It can be hard to parse correctly. Not sure about Atom, though.

CharlesW 9y ago
> RSS is sometimes ambiguous and there's a lot of variation. I've written a reasonably-popular podcast feed validator, and I don't understand either of these criticisms. Mind elaborating?
- bastawhiz 9y ago
  > I've written a reasonably-popular podcast feed validator Mind sharing?
  - dsp1234 9y ago
    https://podba.se/validate/ https://podba.se/validate/
    - bastawhiz 9y ago
      Nice, very cool! Definitely an improvement on the trash legacy validators out there.
  - deleted 9y ago
    [deleted]
- skybrian 9y ago
  Since you've done it recently, I'm sure you know more than I do; I suspect my knowledge of it is obsolete.
- nmcfarl 9y ago
  Not the parent but my company consumed a bit of RSS starting in 2005 (and with the amounts declining to 0 through the years). Over time we've been fed feeds with character encodings not matching what the web server nor the XML declared. Use of undeclared XML namespaces, or quite popular: using elements from other namespaces, without namespaces or declarations -- just shove some nice iTunes things or Atom things into the RSS. Also invalid XML -- just skipping the closing tags was popular. These feeds were from paying customers, and we were not the primary consumers - so when we complained they would generally point to someone else who was consuming it without problem. Sometimes we'd point them at a validator, if they were a small enough customer -- but mostly we just kept working on our in house RSS feed reader that could read tag soup. Things did massively improve over time, and that by the end we were getting _mainly_ reasonably valid RSS.
- thousande 9y ago
  Not been writing XML parsers, but I remember Nick Bradbury the creator of the FeedDemon fame wrote about it a lot 'back in the days', * https://nickbradbury.com/2006/09/21/fixing_funky_fe_1/ https://nickbradbury.com/2006/09/21/fixing_funky_fe_1/ * http://nick.typepad.com/blog/2004/01/feeddemon_and_w.html http://nick.typepad.com/blog/2004/01/feeddemon_and_w.html * https://en.wikipedia.org/wiki/FeedDemon https://en.wikipedia.org/wiki/FeedDemon

jonknee 9y ago

Probably this part: > simpler to read and write

halloij 9y ago
If you're writing these things by hand, you're probably doing something wrong...
- jonknee 9y ago
  JSON is also easier for computers to read and write...
  - halloij 9y ago
    XML generators and parsers have been in use for a decade+. Pretty sure most of the bugs have been found and fixed by now. It's just reinventing the wheel because the new generation don't want to use the same tools the previous generation did. The time and effort spent doing this is quite ridiculous. (FWIW, I hate XML, JSON is far better. But there's more important things to work on).
    - ergothus 9y ago
      > Pretty sure most of the bugs have been found and fixed by now. Given the complexity and what I've seen from some other long established codebases, I don't share your confidence. > It's just reinventing the wheel because the new generation don't want to use the same tools the previous generation did. You can disagree with the decisions involved (as you did with the XML vulnerability argument), but the fact that those arguments exist means they AREN'T doing it just because they don't want to use the same tools the previous generation did - they have different reasons that you think aren't good reasons. Saying it as you did comes across as smug and dismissive, which is not an effective way of convincing your audience that you've taken arguments into account when making your decision.
    - deleted 9y ago
      [deleted]

crdoconnor 9y ago

JSON parsers have a much smaller 'feature surface' meaning that there are fewer nooks and crannies for bugs to live in. One example of a bug that often festered in XML parsers: https://en.wikipedia.org/wiki/Billion_laughs https://en.wikipedia.org/wiki/Billion_laughs (there is no JSON equivalent of this) The generalized theory, for those interested : https://en.wikipedia.org/wiki/Rule_of_least_power https://en.wikipedia.org/wiki/Rule_of_least_power

kr0 9y ago
What from I grok the guy requesting JSON-LD wants this functionality
zokier 9y ago
While I'd agree that parsing JSON is much easier than XML, it is still not completely trivial as demonstrated by this article: http://seriot.ch/parsing_json.php http://seriot.ch/parsing_json.php

StevePerkins 9y ago

I couldn't help but take a dismissive stance toward the rest of the page after reading the first paragraph.

bastawhiz 9y ago

Consider XML entity bombs. You need to explicitly tell your XML parser not to follow the spec to prevent malicious sources of XML from crashing your application. XML also has a lot of room for syntax errors, with many types of tokens and escape rules. JSON, by comparison, does not.

jjawssd 9y ago
> XML also has a lot of room for syntax errors, with many types of tokens and escape rules. JSON, by comparison, does not. Parsing JSON is a minefield. Yellow and light blue boxes highlight the worst situations for applications using the specified parser. Take a look at how a bunch of parsers perform with various payloads: http://seriot.ch/json/pruned_results.png http://seriot.ch/json/pruned_results.png "JSON is the de facto standard when it comes to (un)serialising and exchanging data in web and mobile programming. But how well do you really know JSON? We'll read the specifications and write test cases together. We'll test common JSON libraries against our test cases. I'll show that JSON is not the easy, idealised format as many do believe. Indeed, I did not find two libraries that exhibit the very same behaviour. Moreover, I found that edge cases and maliciously crafted payloads can cause bugs, crashes and denial of services, mainly because JSON libraries rely on specifications that have evolved over time and that left many details loosely specified or not specified at all." More details available at: http://seriot.ch/parsing_json.php http://seriot.ch/parsing_json.php
- floatboth 9y ago
  None of these issues are as bad as the XML ones. You generally don't need "defusedjson" like you need https://pypi.python.org/pypi/defusedxml https://pypi.python.org/pypi/defusedxml <!DOCTYPE external [ <!ENTITY ee SYSTEM "file:///etc/ssh/ssh_host_ed25519_key"> ]> <root>&ee;</root>
- bastawhiz 9y ago
  Parser correctness is irrelevant when you're talking about the ability to be written with few syntax errors. For instance, JSON has one type of string with one set of string escape rules. XML has element names, attribute names, attribute values, text nodes, CDATA content, RCDATA content, and more. And almost all of them have different rules for what they can contain and how they can be used. By comparison, XML is orders of magnitude more complex than JSON.