It can be done like this too:

<fruit> <id>10</id> <name>orange</name> </fruit>

Which one is better? I find it hard to decide, and I believe most people do. And that's why we see it mixed, often in the same XML document.

The one you use is better (correct).

Utterly disagree. Attributes can actually have validated contents, such as enumerated lists, etc, and are attractively terse.

Over-reliance on elements are why Maven pom files are such a verbose disaster, and probably the main reason why web developers puke when trying to stream data. Restating element names make for illegible, bloated data. Attribute-heavy XML is attractively terse and benefits from validation (unlike JSON).

But you can't change an attribute to a composite type in the future easily.

As for maven POMs, I use Netbeans "add dependency" and that's about it so it's a non issue for me.

Far better than either is:

    (fruit (id 10) (name orange))

At least IMHO.

As the joke goes you can write COBOL in any language, and you're the proof.

In JSON a more typical format would be:

    {"id":10,"name":"orange"}

Now why you need an id and a name is another smell, but let's leave that in for the sake of the example.

You don't need "node names" in JSON. Typically objects of type "fruit" will be hosted in an array whose type you're always aware of by the contract of your service.

Sure you can have polymorphism and hint the type in those exceptional cases:

    {"type":"fruit","id":10,"name":"orange"}

But at least you include that if you need it, it signifies intent, and it's not done just to appease a markup language bent out of shape as a serialization format.

By the way, it's curious you chose to use attributes in your XML example. Attributes aren't typically used to serialize object fields. Can you guess why?

You seem to have only one use case which appears to be serialization, that isn't nearly the world of what xml covers. Yeah I guess if you don't want to use a database for your blog application json serialization is fine.

A lot of us need much more from our data than that. We need validation, we need a machine readable description format, and we need apis to leverage all this that doesn't change every day.

The json community is constantly reinventing the latter. Who cares if it saves a few bytes in transmission, I don't know anyone who grumbles "oh great, the xml is making my internet slow today."