I honestly don't like XML, not that there aren't very verbose tools and standards to make it easier to use, but intrinsically you can't look at XML file and know how a codified representation should look like... if you have an element it will have properties and child elements... said child elements may contain children, strings, or ??? ... JSON maps much more naturally to an object model in a given language. That's just one way that by example you can show JSON, and know what you need to make.
Not to mention, XML is much more verbose, and when you wrap it in things like ws*/SOAP it gets really ugly really quickly, and if you don't map everything, it gets complicated and often fails. When you publish a service using one toolkit, it's often difficult to use the service in another toolkit (example, using Java services in .Net gets really painful at times). Unless a lot of detail is done, or an API client in that client's environment is provided.
This isn't about XML specifically but about the environment it tends to create. JSON is typically simpler to write, easier to code against and more forgiving in the tooling than XML is. Much like the differences between a scripted environment and a statically compiled environment.
wait... I don't understand comments like these. You're not the only one to make these claims, but I'll address yours specificially:
> but intrinsically you can't look at XML file and know how a codified representation should look like...
Let's compare:
<book>
<title>How To Be Awesome</title>
<subtitle>Surviving on HN Posts</subtitle>
<author>
<first_name>Max</first_name>
<last_name>Power</last_name>
</author>
</book>
1. need a schema to be useful as a standard
2. express their hierarchy
3. don't specify data type (although I could add that info to both if needed)
4. have a level of annoying to them (commas, colons, angle brackets, etc) which modern IDEs have taken care of for us.
> if you have an element it will have properties and child elements... said child elements may contain children, strings, or ???
I need to use documentation to use `package.json` files too, because each node may or may not contain children. Node graciously tells me if I missed something. Docbook also tells me if my XML is malformed. I see no difference here,
> JSON maps much more naturally to an object model in a given language.
It maps to a hash/dictionary. I'm not sure that qualifies as an "object model" unless you only write JavaScript.
I'd really like people to understand that XML is, like HTML, really great at describing and marking up content so that something else may process it.
You could also have <book title="..." subtitle="..." >... There's no real canonical representation of what an object should look like... can you have more than one title tag for a book? If you look at your xml, you don't know. Can you have more than one author tag? from the xml, you don't know... both of these, you do know looking at the json.
Not to mention, XML is much more verbose, and when you wrap it in things like ws*/SOAP it gets really ugly really quickly, and if you don't map everything, it gets complicated and often fails. When you publish a service using one toolkit, it's often difficult to use the service in another toolkit (example, using Java services in .Net gets really painful at times). Unless a lot of detail is done, or an API client in that client's environment is provided.
This isn't about XML specifically but about the environment it tends to create. JSON is typically simpler to write, easier to code against and more forgiving in the tooling than XML is. Much like the differences between a scripted environment and a statically compiled environment.