7 ms·

JSON is basically XML with 50% less bullshit. I don't get this. XML has the capacity of being as simple as you want it to be. You don't need schemas, namespace

JSON is basically XML with 50% less bullshit. I don't get this. XML has the capacity of being as simple as you want it to be. You don't need schemas, namespaces, xpath, and so on, and can make your XML life every bit as easy as JSON. In many ways easier given that JSON doesn't even have a bloody date or time type. But if you do want strong-type validation, schemas and namespaces are there for you. If you want an easy, standard way to query, XPath/XQuery are there for you. If you want to wholesale completely restructure entire documents/data blobs, XSLT is there for you. I have never gotten the hate for XML. I suspect -- and this is not some sort of slur against those who don't like something I like, but rather is an observation about general tech trends -- that many programmers were simply too lazy to understand all of XML, so rather than work in an area where they felt ignorant (again, nothing stops you from making bespoke XML at your desire), JSON and things like it seem so appealing.

reginaldo 14y ago
I think the 50% less bulshit figure is pretty generous. Let's not forget that, unless you opt out of it, most XML parsers, when given user-generated input, will do lots of crazy stuff. In the best case scenario, the machine that parsed the input will fall victim to DoS. In the worst, we have good old remote code execution. Tipically, an attacker will be able to read lots of files from the servers and make arbitrary network connections, many times from the viewpoint of a machine inside a corporate firewall. As a spare-time security researcher, let's say I absolutely love XML. As a developer, I despise it.
- corresation 14y ago
  I'm sorry, but the vague handwaving about security issues with XML is utter nonsense. There have been issues, just as there have been issues with JSON, HTML, or any other parsed or shared content. Alluding to some vast chasm of danger is absurd, made especially obvious that XML remains the lingua franca or most enterprise systems and interchanges (meaning the ones that people are most interested in trying to compromise).
- reginaldo 14y ago
  corresation: I can't answer your post directly, so I'll answer my own. It's absolutely not vague handwaving. HTML or JSON parsers can't make arbitrary network connections. XML parsers often can. XML remains the lingua franca or most enterprise systems and interchanges (meaning the ones that people are most interested in trying to compromise That is one of the reasons attackers are so happy. They are not trying to compromise. They are succeeding. Show me a SOAP/XMLRPC web service and I will show you a compromised machine, with very high probability. See, for instance, last year's BlackHat presentation about SAP. Root with 1 request. Granted, there was an overflow involved, but the entry point was XML. Many more instances of this are available (I've compromised tens of systems in the last six months through the "magic" of XXEs, but unfortunately can't talk about them). http://media.blackhat.com/bh-us-12/Briefings/Polyakov/BH_US_12_Polyakov_SSRF_Business_Slides.pdf http://media.blackhat.com/bh-us-12/Briefings/Polyakov/BH_US_...
csense 14y ago
1. JSON has an easy way to specify data types. In XML you have to have multiple nested tags. In JSON my document can be: {"mynumber" : 5, "mylist" : ["one", "two", "three"]} Simple, neat, and fits on one line. In XML this has to be <!DOCTYPE some-magic-string-nobody-can-remember> <topnode> <mynumber><int>5</int></mynumber> <mylist> <str>one</str> <str>two</str> <str>three</str> </mylist> </topnode> Of course, I don't know what you're talking about "JSON doesn't even have a bloody date or time type" when XML doesn't have anything but strings. In order to parse this, I'd have to have code which looks for <int> tags and runs my language's atoi() on the content. Maybe there are libraries that do this automatically. If there are, the XML community does an excellent job of hiding them from developers; I've worked a fair bit with XML, and haven't found them. 2. Easy interface with popular languages. You can just copy-paste a JSON string into a Javascript / Python app. (Warning: If you do this programmatically, it's going to be a security vulnerability.) Whereas if you want to use XML, you have to jump through a lot of hoops. Especially with Java; AFAIK the Java standard lib only ships a specification for XML parsing. So while the org.w3c.xml namespace is there (or whatever it's called, it's been a while), you have to install some Apache lib called Xerces or Xalan or Xavier (or whatever it's called, it's been a while) in order to have XML support. This is Java's fault, not XML's; but XML was a shiny cool thing at about the same time Java was, so a lot of peoples' main XML experience (or at least mine) is in Java. 3. Is a subset of many popular languages. A lot of people -- especially web developers -- only know one language. If you know JS, then you know JSON. But XML syntax and semantics is very different from most programming languages, and that's a barrier. (General XML is much different than HTML. In particular, you can always see what HTML "does" by loading it in the browser because everything has default styles; not so with a general XML format, unless you go through the pain of writing a complete style yourself.)
- gutnor 14y ago
  You are a bit outdated, tooling is a bit better nowadays. Java integrates everything you need to parse and generate XML. Most API are XSD driven (either through annotation in the code, or with the mapping code generated from the XSD), so you get plenty of types like data, int, ... You also get streaming parser (pull or push) and DOM. Obviously, that is no longer plain XML, that is XML + XSD + Namespaces. The J2SE (not JEE) also has built-in support to expose and consume webservices, without requiring to worrying about WSDL and the rest. At the end of the day, that does not mean that dealing with XML is a great experience. Most real life XML is awful. And well although the basic tooling is there, that is in the usual java fashion with factories of factory of creator of generator and very little "high level" utility.
ripter 14y ago
I don't understand the complant that JSON doesn't support a date/time format. It supports numbers and strings. You can use unix timestamps, you can use ISO 8601, you can use any format that makes sense for your application. JSON doesn't support a Date/Time object because it's a data format. XML doesn't support a Date/Time object either. Now if you want to complain that the JSON parsers don't automatically convert ISO 8601 dates into Date/Time objects, I understand. To me 50% less bullshit means 50% less typing and maybe getting something wrong. JSON is easy to read and write by hand, which happens a lot. XPath/XQuery and XSLT are nightmares in my opinion. I'd much rather type `Foo.bar` or `_.each(Foo.items, function(item) {...})` and be able to easily debug when something goes wrong.
- emn13 14y ago
  Right, but xml "objects" are annotated with some name, whereas json nodes aren't. This is a hassle, but it's also very convenient when you want to represent something that doesn't map 100% perfectly onto the underlying structure. So as you say, you _could_ represent a date in lots of different ways. In xml that's doable, and somewhat comprehensible. In JSON it's usually jibberish. And that's just dates - good luck with anything more complex. I still think JSON is a more promising format in the long run. But it certainly isn't great - it's just bad in a different way, and somewhat more minimalist (which is good). Also, I can't for the life of me understand why someone would dislike xpath. It's like the one best thing about xml - it's simple, concise, and easy to read. I'd absolutely love an xpath equivalent for json, which just doesn't exist. Just expressing obvious things like "person[name='bla']/nickname" is so much more wordy in an explicit function style. And notice how the rest of the world - including most major js(on) libs have long gravitated towards that (monadic) style of querying - it's not just me, almost everyone prefers it. CSS; SQL; jquery selectors; even a filesystem glob - every complex datastore gravitates to some variant of the same pattern, and it's something json consuming libs do not yet do very well. I'm sure they will someday - but it's a real lack right now.
- corresation 14y ago
  JSON doesn't support a Date/Time object because it's a data format. XML doesn't support a Date/Time object either. XML doesn't support objects, but there was enough thought put into the implementation that it has an easy way to document and define the types, with validated ways of representation. ISO 8601 for the xsd:dateTime, for instance. There is no ambiguity or uncertainty, no hand-rolled varieties of crazy, quite unlike JSON world where there are a hundred ways to represent a date or date/time, all of them broken in some way or other.
ramses0 14y ago
XML has a few issues compared to JSON: * attributes v. tagnames * no "anonymous list" * infinitely large surface area [ {name: joe, age: 12 }, {name: bob, age: 23} ] <list><user><name>joe</name><age>12</age></user><user><name>bob</name><age>23</age></user></list> The access pattern for json is much easier: obj[1].name The infinitely large surface area of XML is painful. Namespaces, entities, xsd/schema, cdata, cdata-in-cdata. It's an alright data / interchange format and especially suited to certain multi-vendor use cases, but the disadvantages cost more than the benefits compared to "simple" anonymous json.
- jodrellblank 14y ago
  <user name='joe' age='12' />
  - huherto 14y ago
    What about bob?
    - jodrellblank 14y ago
      I'm sure you're capable of filling in the pattern with <user name='bob' age='23' /> yourself. I wasn't trying to show XML is as compact as JSON, only that it can be more compact than the claim "it's so verbose" made it look.
      - coldtea 14y ago
        Yes. And then you have to find a way to parse that. JSON always comes with ready made parsing.
    - ncote 14y ago
      Man, that was funny!
- mattmanser 14y ago
  {'users': [{'name': 'joe', 'age': '12' }, {'name': 'bob', 'age': '23'}]} <users><user name='joe' age='12' /><user name='bob' age='23' /></users>
seanalltogether 14y ago
XML has the capacity of being as simple as you want it to be Unfortunately in practice it never is. I've seen programmers do too many dumb things with data structures in XML, which then becomes "part of the spec" so it never goes away. Take an xml api in a fortune 500 and run it through 10 developers over the course of 5 years, then do the same thing with a json api, I guarantee you the json one will be more standardized and easier to consume.
- ams6110 14y ago
  Guarantee? Do you actually know how "enterprise" projects work?
  - seanalltogether 14y ago
    bank of america, t. rowe price, wall st on demand, ebay, aflac, adobe, ge, nielson, navy federal...do you want me to open my entire client archive? You should see what java devs try to shove into xml structures.
jgalt212 14y ago
XML is good when the structure of the data returned is not self-evident to the data requester. In this case XML's verbosity assists in hand walking the tree to grok what the server is returning. XLST is a friggin nightmare to code and I can't think of any reason why one would want to use it. It's much better to first parse the XML and then reshape to your needs rather than trying to do both at the same which XSLT does. In short, XSLT violates separation of conerns. Furthermore, if you think XML is hard to read, just try reading someone else's XL
EdiX 14y ago
> I don't get this. XML has the capacity of being as simple as you want it to be. You don't need schemas, namespaces, xpath XML data model (trees with attributed nodes and special kinds of leaves) is not native to any language: XPath/XQuery and XSLT exist to bridge the alien world of XML to regular programming languages. Taking them out doesn't make XML simpler. JSON doesn't have them because it can be represented with maps and lists, object types fundamental to many programming languages (it practically maps almost exactly to every scripting language created in the last 20 years). That's why it doesn't have, and doesn't need, XPath or XSLT equivalents. And that's also why it feels more natural to most programmers (ie. 50% less bullshit). You could build a stronger case for the need of schemas and namespaces but IMHO that's actually bullshit, even in XML. But you can ignore them in XML too, as you noted, so it doesn't really matter.

reginaldo 14y ago

I think the 50% less bulshit figure is pretty generous. Let's not forget that, unless you opt out of it, most XML parsers, when given user-generated input, will do lots of crazy stuff. In the best case scenario, the machine that parsed the input will fall victim to DoS. In the worst, we have good old remote code execution. Tipically, an attacker will be able to read lots of files from the servers and make arbitrary network connections, many times from the viewpoint of a machine inside a corporate firewall. As a spare-time security researcher, let's say I absolutely love XML. As a developer, I despise it.

corresation 14y ago
I'm sorry, but the vague handwaving about security issues with XML is utter nonsense. There have been issues, just as there have been issues with JSON, HTML, or any other parsed or shared content. Alluding to some vast chasm of danger is absurd, made especially obvious that XML remains the lingua franca or most enterprise systems and interchanges (meaning the ones that people are most interested in trying to compromise).
reginaldo 14y ago
corresation: I can't answer your post directly, so I'll answer my own. It's absolutely not vague handwaving. HTML or JSON parsers can't make arbitrary network connections. XML parsers often can. XML remains the lingua franca or most enterprise systems and interchanges (meaning the ones that people are most interested in trying to compromise That is one of the reasons attackers are so happy. They are not trying to compromise. They are succeeding. Show me a SOAP/XMLRPC web service and I will show you a compromised machine, with very high probability. See, for instance, last year's BlackHat presentation about SAP. Root with 1 request. Granted, there was an overflow involved, but the entry point was XML. Many more instances of this are available (I've compromised tens of systems in the last six months through the "magic" of XXEs, but unfortunately can't talk about them). http://media.blackhat.com/bh-us-12/Briefings/Polyakov/BH_US_12_Polyakov_SSRF_Business_Slides.pdf http://media.blackhat.com/bh-us-12/Briefings/Polyakov/BH_US_...

csense 14y ago

1. JSON has an easy way to specify data types. In XML you have to have multiple nested tags. In JSON my document can be: {"mynumber" : 5, "mylist" : ["one", "two", "three"]} Simple, neat, and fits on one line. In XML this has to be <!DOCTYPE some-magic-string-nobody-can-remember> <topnode> <mynumber><int>5</int></mynumber> <mylist> <str>one</str> <str>two</str> <str>three</str> </mylist> </topnode> Of course, I don't know what you're talking about "JSON doesn't even have a bloody date or time type" when XML doesn't have anything but strings. In order to parse this, I'd have to have code which looks for <int> tags and runs my language's atoi() on the content. Maybe there are libraries that do this automatically. If there are, the XML community does an excellent job of hiding them from developers; I've worked a fair bit with XML, and haven't found them. 2. Easy interface with popular languages. You can just copy-paste a JSON string into a Javascript / Python app. (Warning: If you do this programmatically, it's going to be a security vulnerability.) Whereas if you want to use XML, you have to jump through a lot of hoops. Especially with Java; AFAIK the Java standard lib only ships a specification for XML parsing. So while the org.w3c.xml namespace is there (or whatever it's called, it's been a while), you have to install some Apache lib called Xerces or Xalan or Xavier (or whatever it's called, it's been a while) in order to have XML support. This is Java's fault, not XML's; but XML was a shiny cool thing at about the same time Java was, so a lot of peoples' main XML experience (or at least mine) is in Java. 3. Is a subset of many popular languages. A lot of people -- especially web developers -- only know one language. If you know JS, then you know JSON. But XML syntax and semantics is very different from most programming languages, and that's a barrier. (General XML is much different than HTML. In particular, you can always see what HTML "does" by loading it in the browser because everything has default styles; not so with a general XML format, unless you go through the pain of writing a complete style yourself.)

gutnor 14y ago
You are a bit outdated, tooling is a bit better nowadays. Java integrates everything you need to parse and generate XML. Most API are XSD driven (either through annotation in the code, or with the mapping code generated from the XSD), so you get plenty of types like data, int, ... You also get streaming parser (pull or push) and DOM. Obviously, that is no longer plain XML, that is XML + XSD + Namespaces. The J2SE (not JEE) also has built-in support to expose and consume webservices, without requiring to worrying about WSDL and the rest. At the end of the day, that does not mean that dealing with XML is a great experience. Most real life XML is awful. And well although the basic tooling is there, that is in the usual java fashion with factories of factory of creator of generator and very little "high level" utility.

ripter 14y ago

I don't understand the complant that JSON doesn't support a date/time format. It supports numbers and strings. You can use unix timestamps, you can use ISO 8601, you can use any format that makes sense for your application. JSON doesn't support a Date/Time object because it's a data format. XML doesn't support a Date/Time object either. Now if you want to complain that the JSON parsers don't automatically convert ISO 8601 dates into Date/Time objects, I understand. To me 50% less bullshit means 50% less typing and maybe getting something wrong. JSON is easy to read and write by hand, which happens a lot. XPath/XQuery and XSLT are nightmares in my opinion. I'd much rather type `Foo.bar` or `_.each(Foo.items, function(item) {...})` and be able to easily debug when something goes wrong.

emn13 14y ago
Right, but xml "objects" are annotated with some name, whereas json nodes aren't. This is a hassle, but it's also very convenient when you want to represent something that doesn't map 100% perfectly onto the underlying structure. So as you say, you _could_ represent a date in lots of different ways. In xml that's doable, and somewhat comprehensible. In JSON it's usually jibberish. And that's just dates - good luck with anything more complex. I still think JSON is a more promising format in the long run. But it certainly isn't great - it's just bad in a different way, and somewhat more minimalist (which is good). Also, I can't for the life of me understand why someone would dislike xpath. It's like the one best thing about xml - it's simple, concise, and easy to read. I'd absolutely love an xpath equivalent for json, which just doesn't exist. Just expressing obvious things like "person[name='bla']/nickname" is so much more wordy in an explicit function style. And notice how the rest of the world - including most major js(on) libs have long gravitated towards that (monadic) style of querying - it's not just me, almost everyone prefers it. CSS; SQL; jquery selectors; even a filesystem glob - every complex datastore gravitates to some variant of the same pattern, and it's something json consuming libs do not yet do very well. I'm sure they will someday - but it's a real lack right now.
corresation 14y ago
JSON doesn't support a Date/Time object because it's a data format. XML doesn't support a Date/Time object either. XML doesn't support objects, but there was enough thought put into the implementation that it has an easy way to document and define the types, with validated ways of representation. ISO 8601 for the xsd:dateTime, for instance. There is no ambiguity or uncertainty, no hand-rolled varieties of crazy, quite unlike JSON world where there are a hundred ways to represent a date or date/time, all of them broken in some way or other.

ramses0 14y ago

XML has a few issues compared to JSON: * attributes v. tagnames * no "anonymous list" * infinitely large surface area [ {name: joe, age: 12 }, {name: bob, age: 23} ] <list><user><name>joe</name><age>12</age></user><user><name>bob</name><age>23</age></user></list> The access pattern for json is much easier: obj[1].name The infinitely large surface area of XML is painful. Namespaces, entities, xsd/schema, cdata, cdata-in-cdata. It's an alright data / interchange format and especially suited to certain multi-vendor use cases, but the disadvantages cost more than the benefits compared to "simple" anonymous json.

jodrellblank 14y ago
<user name='joe' age='12' />
- huherto 14y ago
  What about bob?
  - jodrellblank 14y ago
    I'm sure you're capable of filling in the pattern with <user name='bob' age='23' /> yourself. I wasn't trying to show XML is as compact as JSON, only that it can be more compact than the claim "it's so verbose" made it look.
    - coldtea 14y ago
      Yes. And then you have to find a way to parse that. JSON always comes with ready made parsing.
  - ncote 14y ago
    Man, that was funny!
mattmanser 14y ago
{'users': [{'name': 'joe', 'age': '12' }, {'name': 'bob', 'age': '23'}]} <users><user name='joe' age='12' /><user name='bob' age='23' /></users>

seanalltogether 14y ago

XML has the capacity of being as simple as you want it to be Unfortunately in practice it never is. I've seen programmers do too many dumb things with data structures in XML, which then becomes "part of the spec" so it never goes away. Take an xml api in a fortune 500 and run it through 10 developers over the course of 5 years, then do the same thing with a json api, I guarantee you the json one will be more standardized and easier to consume.

ams6110 14y ago
Guarantee? Do you actually know how "enterprise" projects work?
- seanalltogether 14y ago
  bank of america, t. rowe price, wall st on demand, ebay, aflac, adobe, ge, nielson, navy federal...do you want me to open my entire client archive? You should see what java devs try to shove into xml structures.

jgalt212 14y ago

XML is good when the structure of the data returned is not self-evident to the data requester. In this case XML's verbosity assists in hand walking the tree to grok what the server is returning. XLST is a friggin nightmare to code and I can't think of any reason why one would want to use it. It's much better to first parse the XML and then reshape to your needs rather than trying to do both at the same which XSLT does. In short, XSLT violates separation of conerns. Furthermore, if you think XML is hard to read, just try reading someone else's XL

EdiX 14y ago

> I don't get this. XML has the capacity of being as simple as you want it to be. You don't need schemas, namespaces, xpath XML data model (trees with attributed nodes and special kinds of leaves) is not native to any language: XPath/XQuery and XSLT exist to bridge the alien world of XML to regular programming languages. Taking them out doesn't make XML simpler. JSON doesn't have them because it can be represented with maps and lists, object types fundamental to many programming languages (it practically maps almost exactly to every scripting language created in the last 20 years). That's why it doesn't have, and doesn't need, XPath or XSLT equivalents. And that's also why it feels more natural to most programmers (ie. 50% less bullshit). You could build a stronger case for the need of schemas and namespaces but IMHO that's actually bullshit, even in XML. But you can ignore them in XML too, as you noted, so it doesn't really matter.