|Problems? Is your data what you think it is?|
I'm not sure what kind of answer you're expecting.
"XML sux! JSON rules!" ?
I have a hard time imagining any data that I'd rather get in XML than in JSON. No, actually, I am completely failing to imagine data that I'd rather get in XML than in JSON.
Have you ever tried to deal with an XML parser? What a recipe for frustration! Have you ever tried to programmatically generate XML? I find that to be an excellent way to find many modules that provide cumbersome (and worse) interfaces for a task.
I guess XML has the potential to let you create a DTD (or even just namespaces). Though, I have yet to have a DTD actually prove useful (and my experience with XML namespaces is "100% pain" so far). I can see the theoretical benefit of such. But, no, I don't see that out-weighing the many other significant pains from dealing with XML. I think the need to invent the complex thing that is a DTD is mostly a demonstration of how painful XML is to work with, creating the need for advanced tools to compensate.
Then there is the complete refusal of XML to allow "data" to include something as mundane as a form-feed character. Sure, you can come up with some additional encoding to embed into the XML... For example, you could encode your binary data into the extremely simple and capable format of JSON and then embed the JSON into the XML.
I also sometimes wish JSON allowed for comments and ordered pairs. But, really, you can just use a list for ordered pairs. And there are even advantages for defining how to include the comments as part of the data (if you don't want to just go slightly outside the JSON standard and allow Java-style comments). (And I sometimes wish JSON didn't allow any types of scalar data other than strings.)
I guess using JSON as a mark-up language for a 98%-text document (like a web page) seems a bit strange. But I suspect, in practice, if you define the structure well, it won't be any worse than trying to edit HTML. But that's a bit of a stretch for something that I'd call "data" anyway.
Pretty much when I say "data", I mean "something that fits in JSON". JSON came along and nicely defined the crux of "what is data?" when talking about sending data between end-points not confined to a single process. It is just too bad that it wasn't formalized much earlier. It would've greatly simplified the HTTP protocol, for example.