{"mynumber" : 5, "mylist" : ["one", "two", "three"]}

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>

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.)

Point #2 isn't very strong. Every language has good support for both technologies these days.

Point #3 is absurd. If you know JS and you know HTML, you're not far from the basics of XML. If you're contemplating JSON as a replacement, you're either assuming our poor web developer is really stupid or you're comparing apples to oranges.

In general, your argument here is that JSON is shorter and more popular. Sure. But unless your top concern is bandwidth (hey, maybe it is) there might exist other technical reasons to make the choice which are less childish.

2. Maven is a nightmare too. Every time I've used it (usually because I'm compiling someone else's code and they wrote the build in maven), it downloads hundreds of megabytes of who-knows-what from random Internet sites. I want to pin versions of dependencies (and dependencies-of-dependencies) so my builds are repeatable, and I want to be sure everyone who's forked my git repo can still build the code if the Maven URL's for the deps have gone out of business. I recall trying to read the Maven manual, but both the manual and the concepts were incomprehensible -- there's so much automagic, when things break, it's difficult to even come up with a hypothesis of what might be going wrong. (And anyone who has any experience with any build system knows that the build always breaks.)

I usually just use Ant. It's a bit of a pain shuttling jar's around (symlinks help), but at least I can understand the build.

3. Part of the problem is that I don't want this alphabet soup of technologies. If I'm running in Python, and I'm developing a prototype or a one-off hack, I just write a file called whatever.py. (I can "import json" in whatever.py if I don't want to use hacks like eval()/repr() or copy-and-paste for parsing/serializing.)

I want to be able to build a quick one-file prototype to process my XML, without enabling the "Java EE 6 web profile" (whatever that is) and writing a Maven build file. I want using XML to be this simple:

  sudo apt-get install default-jdk
  javac Whatever.java && java Whatever

2. You may not like Maven--I hate it too--but it's how things are done. In practice the only people complaining about installing libraries and managing jar dependencies are people using ant without ivy. 90% of folks just use Maven and get on with it.

3. You're turning your complaint from "Java's XML support is weak" to "Java's XML support isn't Pythonic like Python's." This is a weak argument. You're saying you want to live the Python dream in Javaland. Well, it isn't going to happen, no matter what the Play guys tell you. But if you have to use Java--and sometimes you do--adding four lines to your maven config--which you will have--so you can use EE 6 or JAXB is not a big deal, and neither is putting a few annotations on a class.

I don't love Java. In fact I dislike it. I would rather be using Haskell, Python, or Ruby. Or any number of other things. But you can't be mad at Java for being Java and not Python.

That's by default in maven - you have to do something really stupid to get non-repeatable builds (usually involves specifying open version ranges or some weird plugin magic)

>everyone who's forked my git repo can still build the code if the Maven URL's for the deps have gone out of business

One of the main advantages of maven is just the opposite of that - you don't have to bundle your dependencies and get them to other people - they can just ask maven to fetch them. And maven is not going away.

I think they changed it now but for years the default behaviour was to get the latest versions of every plugin, making builds non-repeatable by default.

This got me up to speed pretty quickly to learn JAX-RS providing XML and JSON.

<http://androidexample.com/Camera_Photo_Capture_And_Show_Capt...

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.

The S stands for simple... <<Sob>>

* 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.

  <user name='joe' age='12' />

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.

JSON always comes with ready made parsing.

    {'users': [{'name': 'joe', 'age': '12' }, {'name': 'bob', 'age': '23'}]}
    <users><user name='joe' age='12' /><user name='bob' age='23' /></users>

{ name: 'joe', dob: { m: 1, d: 2, y: 1934 } }

<user name='joe' dob='...???...'>

<user><name>joe</name><dob><m>1</m><d>2</d><y>1934</y></dob></user>

I actually wasn't trying to make the "XML is bigger" joke because that isn't what's important to me. Structurally XML is harder to use.

    {users: [{name: 'joe', age: 12}, {name: 'bob', age: 23}]}
    <users><user name='joe' age='12' /><user name='bob' age='23' /></users>

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.

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.

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.

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.

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_...

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

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.