Agreed. Take the example of people hating XML and trying to reinvent everything good XML already had with JSON and JSON Schema. http://json-schema.org/
My biggest peeve with XML is there's no concrete way to represent a piece of XML in code, it's in my opinion TOO flexible. You can express something as an attribute, a child, multiple children of the same element, a value of a child, etc. It doesn't translate cleanly to any kind of object structure in terms of code. And it goes in reverse too.
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.
That's because originally SGML/HTML/XML attributes were for (mostly) presentational details, but this role was shifted to CSS. The resulting combination does indeed look arbitrary, especially with CSS's total lack of mental discipline (but let's not be too harsh here).
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.
Looking at the other comments, I realize you're looking for object/XML mapping. My opinion is that this is pointless (and I'm guilty of applying it back in the SOAP days, too), because objects are co-inductive data structures based on the types of programming languages, whereas XML is based on grammars eg. a description of a class of sequences of content tokens.
Sure you can represent objects, ie. a memory dump of a running program, as XML, but what's the point?
I am not sure if you had chance to play with JAXB, it maps xml very cleanly to java objects. I mean you can have the whole darn thing define inheritance and it would generate the corresponding relation in Objects too.
IMO It just needs to be given some consideration before rejecting as old bloated piece of crap.
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.
It couldn't. That would mean a different thing and would be the abuse of what XML should be used for.
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."
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.