[DaiPlusPlus]

I don't mean the current verbose JSON standard (e.g. string keys, no comments) but something derived from it - because XML's capabilities are a subset of what JS/JSON is capable of, and because the same syntax for complex properties can be used for trivial properties it simplifies the syntax, for example:

<Foo Trivial="trivial"> <Foo.Complex> <Bar Bound="{Binding qux}" /> </Foo.Complex> </Foo>

Could be represented in strict JSON as:

{ "Type": "Foo", "Trivial": "trivial", "Complex": { "Type": "Bar", "Bound": { "Type": "Binding", "Path": "qux" } } }

A more succint JSON-derivative would allow for the "Type" property to be specified anonymously, object keys as identifiers, not strings, allow comments, and use object constructors directly instead of object literals:

{ Foo, Trivial: "trivial", Complex: { Bar, Bound: new Binding( "qux" ) }

}

[pjmlp]

> because XML's capabilities are a subset of what JS/JSON is capable of,

It is the other way around, JSON is a subset of XML features.

XML is a very expressive language/file format.

[DaiPlusPlus]

If you widen JSON to be strictly pure JavaScript object and value literals (e.g. allow comments, non-string keys, use of constructor calls, etc) then JSON is more expressive because each child of a JSON object itself is a JSON object - whereas an XML element has two distinct types of children: child-elements and child-attributes, and the expressiveness of attributes is considerably limited compared to child-elements. Granted, JSON provides no inherent way to denote an attribute compared to a child element, but remember that XML restricts you to a single complex child element collection, whereas with JSON you can have multiple properties containing children (unless you want to argue that named element children could correspond with named complex properties in JSON - then it's just a matter of syntax).