Right, but xml "objects" are annotated with some name, whereas json nodes aren't. This is a hassle, but it's also very convenient when you want to represent something that doesn't map 100% perfectly onto the underlying structure. So as you say, you _could_ represent a date in lots of different ways. In xml that's doable, and somewhat comprehensible. In JSON it's usually jibberish. And that's just dates - good luck with anything more complex.

I still think JSON is a more promising format in the long run. But it certainly isn't great - it's just bad in a different way, and somewhat more minimalist (which is good).

Also, I can't for the life of me understand why someone would dislike xpath. It's like the one best thing about xml - it's simple, concise, and easy to read. I'd absolutely love an xpath equivalent for json, which just doesn't exist.

Just expressing obvious things like "person[name='bla']/nickname" is so much more wordy in an explicit function style. And notice how the rest of the world - including most major js(on) libs have long gravitated towards that (monadic) style of querying - it's not just me, almost everyone prefers it. CSS; SQL; jquery selectors; even a filesystem glob - every complex datastore gravitates to some variant of the same pattern, and it's something json consuming libs do not yet do very well. I'm sure they will someday - but it's a real lack right now.