[tracker1]

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.

[tannhaeuser]

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.

[tannhaeuser]

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?

[tracker1]

If it doesn't map cleanly to a program representation in some way, then what is the point, when it's harder to do real work with?

[kul_]

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.

[sly010]

> It doesn't translate cleanly to any kind of object structure in terms of code.

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.

[tracker1]

But that's not concrete without another definition in place

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

[sly010]

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

[Ziomislaw]

> there's no concrete way to represent a piece of XML in code

unless you are using some lisp-2 dialect