5 ms·

Other than smaller bandwidth on each call, what advantages does JSON provide over XML?

kennu 16y ago
Direct mapping to most (dynamic) programming languages' datatypes, such as arrays, dictionaries, numbers and strings. Once you get used to working with a combination like JSON and Python, you really don't want to go back to the complexity and inconvenience of parsing and generating XML.
- d0m 16y ago
  But still, deprecating XML means lots of already functional apps won't work anymore. Maybe a "All new app registered after X date will only be able to use JSON formatted data" would be better.
  - simonw 16y ago
    They're not ditching XML for their regular APIs, just for the streaming API - which has been in beta for just a few months, and probably doesn't have that many XML clients (I imagine Twitter looked at the number of requests the XML endpoint was getting before deciding to deprecate it).
zdw 16y ago
Benefits JSON > XML: Less bandwidth for same data, Quick to load, quick to parse. Very web friendly. Benefits of XML > JSON: Easy to validate structure and content (via schemas), and transform content in a language neutral manner (via xslt). Older, thus supported in more places. Use what works - JSON is fine for web stuff, XML is better for things that need strict validation and/or long term data storage.
- deleted 16y ago
  [deleted]
- andrewvc 16y ago
  I never really got the 'why' behind XML Schemas. Why would you validate a document with a schema vs actual code? It's just a bigger pain in the ass, and more limited.
  - RodgerTheGreat 16y ago
    If you have multiple applications using a document format, XML schemas are a good way to make sure they all agree on the semantics of the format. Recall that XML was originally intended as a means of bridging different environments and platforms, where code will not necessarily be portable.
    - andrewvc 16y ago
      I guess, but even if that's the case, who cares if the message is formatted right if it's still invalid. I guess I haven't really worked in a heterogenous environment with a lot of XML before though, I can see the potential value there, but i'm still doubtful.
      - zdw 16y ago
        The big win for schemas is being able to use them to make assumptions about input, which simplifies your code. For example, if you have an RelaxNG schema (which has a great compact syntax) that says that an element has to have at least one child node and that child node contains an integer between a certain set of values. Once you have that schema, you could write code that could read in the XML file and validate it against the schema in 2 lines, then grab all the child node integers with one XPath expression. The data might be junk (heck, I'm not aware of any format that is impervious to worthless data), but at least it's junk in the right format, and you never had to mess around with parsing the input. Need to switch programming environments or languages because you're working on Unix/Windows/embedded system/mainframe/database/web browser ? The schema can move with you (or be converted to another schema format that does), and programming niceties SAX and XPath will often carry over too.
        16y ago
- brunoc 16y ago
  Regarding schemas - there is JSON Schema: http://json-schema.org/ http://json-schema.org/ http://tools.ietf.org/html/draft-zyp-json-schema-02 http://tools.ietf.org/html/draft-zyp-json-schema-02 We've been using this pretty extensively at work. The Java guys wrote something to generate their model from it and on the JavaScript side we've used it to do all kinds of nice things like automagically generating forms that validate according to the schema and verifying that the data we receive from the backend conforms to it in our tests. From what I can gather very few people are using it. It's not exactly fun to write but a co-worker of mine wrote a dsl to make that less painful. Of course when you write JavaScript, it's a joy to work with. On the transformation side there are a few ideas floating, notably JSON-T http://goessner.net/articles/jsont/ http://goessner.net/articles/jsont/ Neither of these things are as mature as XSD and XSLT, but if you love JSON and JavaScript, they're definitely worth investigating.
  - zdw 16y ago
    Using a schema to frontend/backend form validation sounds totally awesome from a "don't repeat yourself" perspective. If that code becomes worthy of public release, I'd bet it could dramatically raise the profile of JSON Schema.
simonw 16y ago
Here's a piece I wrote about JSON v.s. XML back in 2006: http://simonwillison.net/2006/Dec/20/json/ http://simonwillison.net/2006/Dec/20/json/
RodgerTheGreat 16y ago
XML is actually very hairy and complicated. Consider entity encoding, whitespace (as in xml:space="preserve"), and namespaces. In contrast, the complete syntax of JSON is given in 5 simple flowcharts: http://json.org/ http://json.org/ Nearly any competent programmer could hand-roll a tested, production-ready JSON parser in under a week. Try doing the same with XML. In practice there are plenty of JSON parsers out there to choose from, but being able to completely wrap your head around something is useful.
- dkarl 16y ago
  I upvoted your comment for the info, but I have no idea why this is an advantage for anyone except the handful of people who create an implementation. Hand-rolling an XML parser is a pretty sure sign of a certain kind of incompetence. Wouldn't the same be true of hand-rolling a JSON parser, unless you're one of the (rare) first guys to solve the problem for your language or language platform? To put it another way, wouldn't this only have been an advantage before XML libraries became commonplace? The last time I reached for an XML library and found there was none already installed with my platform, I was using Tcl (and it wasn't hard to find TclXML.)

kennu 16y ago

Direct mapping to most (dynamic) programming languages' datatypes, such as arrays, dictionaries, numbers and strings. Once you get used to working with a combination like JSON and Python, you really don't want to go back to the complexity and inconvenience of parsing and generating XML.

d0m 16y ago
But still, deprecating XML means lots of already functional apps won't work anymore. Maybe a "All new app registered after X date will only be able to use JSON formatted data" would be better.
- simonw 16y ago
  They're not ditching XML for their regular APIs, just for the streaming API - which has been in beta for just a few months, and probably doesn't have that many XML clients (I imagine Twitter looked at the number of requests the XML endpoint was getting before deciding to deprecate it).

zdw 16y ago

Benefits JSON > XML: Less bandwidth for same data, Quick to load, quick to parse. Very web friendly. Benefits of XML > JSON: Easy to validate structure and content (via schemas), and transform content in a language neutral manner (via xslt). Older, thus supported in more places. Use what works - JSON is fine for web stuff, XML is better for things that need strict validation and/or long term data storage.

deleted 16y ago
[deleted]
andrewvc 16y ago
I never really got the 'why' behind XML Schemas. Why would you validate a document with a schema vs actual code? It's just a bigger pain in the ass, and more limited.
- RodgerTheGreat 16y ago
  If you have multiple applications using a document format, XML schemas are a good way to make sure they all agree on the semantics of the format. Recall that XML was originally intended as a means of bridging different environments and platforms, where code will not necessarily be portable.
  - andrewvc 16y ago
    I guess, but even if that's the case, who cares if the message is formatted right if it's still invalid. I guess I haven't really worked in a heterogenous environment with a lot of XML before though, I can see the potential value there, but i'm still doubtful.
    - zdw 16y ago
      The big win for schemas is being able to use them to make assumptions about input, which simplifies your code. For example, if you have an RelaxNG schema (which has a great compact syntax) that says that an element has to have at least one child node and that child node contains an integer between a certain set of values. Once you have that schema, you could write code that could read in the XML file and validate it against the schema in 2 lines, then grab all the child node integers with one XPath expression. The data might be junk (heck, I'm not aware of any format that is impervious to worthless data), but at least it's junk in the right format, and you never had to mess around with parsing the input. Need to switch programming environments or languages because you're working on Unix/Windows/embedded system/mainframe/database/web browser ? The schema can move with you (or be converted to another schema format that does), and programming niceties SAX and XPath will often carry over too.
      - 16y ago
brunoc 16y ago
Regarding schemas - there is JSON Schema: http://json-schema.org/ http://json-schema.org/ http://tools.ietf.org/html/draft-zyp-json-schema-02 http://tools.ietf.org/html/draft-zyp-json-schema-02 We've been using this pretty extensively at work. The Java guys wrote something to generate their model from it and on the JavaScript side we've used it to do all kinds of nice things like automagically generating forms that validate according to the schema and verifying that the data we receive from the backend conforms to it in our tests. From what I can gather very few people are using it. It's not exactly fun to write but a co-worker of mine wrote a dsl to make that less painful. Of course when you write JavaScript, it's a joy to work with. On the transformation side there are a few ideas floating, notably JSON-T http://goessner.net/articles/jsont/ http://goessner.net/articles/jsont/ Neither of these things are as mature as XSD and XSLT, but if you love JSON and JavaScript, they're definitely worth investigating.
- zdw 16y ago
  Using a schema to frontend/backend form validation sounds totally awesome from a "don't repeat yourself" perspective. If that code becomes worthy of public release, I'd bet it could dramatically raise the profile of JSON Schema.

simonw 16y ago

Here's a piece I wrote about JSON v.s. XML back in 2006: http://simonwillison.net/2006/Dec/20/json/ http://simonwillison.net/2006/Dec/20/json/

RodgerTheGreat 16y ago

XML is actually very hairy and complicated. Consider entity encoding, whitespace (as in xml:space="preserve"), and namespaces. In contrast, the complete syntax of JSON is given in 5 simple flowcharts: http://json.org/ http://json.org/ Nearly any competent programmer could hand-roll a tested, production-ready JSON parser in under a week. Try doing the same with XML. In practice there are plenty of JSON parsers out there to choose from, but being able to completely wrap your head around something is useful.

dkarl 16y ago
I upvoted your comment for the info, but I have no idea why this is an advantage for anyone except the handful of people who create an implementation. Hand-rolling an XML parser is a pretty sure sign of a certain kind of incompetence. Wouldn't the same be true of hand-rolling a JSON parser, unless you're one of the (rare) first guys to solve the problem for your language or language platform? To put it another way, wouldn't this only have been an advantage before XML libraries became commonplace? The last time I reached for an XML library and found there was none already installed with my platform, I was using Tcl (and it wasn't hard to find TclXML.)