Now, there are standards like SOAP, etc... In the end, JSON and some clear docs for an API is usually easier to reason with than any of the boatloads of cruft that came along with XML. Not to mention the much larger transmission size.
IMO It just needs to be given some consideration before rejecting as old bloated piece of crap.
In judging whether something should be represented as element text or as attribute, ask yourself whether that something is content or metadata. In a context where this distinction doesn't make sense, markup (SGML, XML, HTML) probably doesn't make sense either.
Markup isn't and never was intended for representing arbitrary data - it is for representing text with optional markup, and is designed for end-users and content authors, not necessarily web developers.
As for representing XML in code, there was E4X which allowed you to represent XML literals in Javascript (Firefox and rhino had it a couple years ago, but it kindof wasn't convincing). Keep in mind that Javascript was invented as a language to manipulate a DOM in the first place, so there you have your canonical representation of markup in Javascript.
Sure you can represent objects, ie. a memory dump of a running program, as XML, but what's the point?
XML translates great to an object tree in many object oriented language.
<foo bar="1">
<yo />
Hello
</foo>
new foo(new yo(), "hello", bar = 1)
Which is why it's so great to describe documents and static UIs.I agree though that it's not a great choice for a REST API.
<foo yo="true">
<bar>1</bar>
<value>Hello</value>
</foo>
Could represent the same object structure, for example. JSON is a pretty clean mapping to objects/properties/arrays, with less chance of confusion, or alternate interpretations.Whether something is inside an element or is a property of said element has important semantical meaning. But not just that, with XML you can implicitly represent ordering, whitespace and type information with much less boilerplate.
So the argument for JSON is basically boils down to: "Javascript has horrible type support and doesn't support OOP. JSON models that experience better."
unless you are using some lisp-2 dialect