For what purpose? Document specifications, data serialization, schema-ful data?<p>JSON's data model lines up much better with common data structures in programming languages, while the often-maligned child-element vs. attribute distinction in XML makes a lot of sense to me to distinguish between globally relevant metadata (attributes) vs. data that can stand on its own (elements).<p>When HTTP APIs started winning out at the expense of SOAP or XML-RPC APIs, JSON became preferred because there was no schema to validate and a client could just parse out the fields they were interested in and ignore the rest.<p>Nowadays, more and more deployments add a JSON Schema, officially discouraging that practice and negating one unique differentiator it had versus XML. They're both text-based formats you have to parse, and for internal, non-outward-facing purposes I'd rather use a binary serialization format instead for compactness and because I control both endpoints.<p>My other preferences are, for outward-facing purposes (like a HTTP API return payload), a custom mediatype based on JSON or XML (in that order, because JSON has more community goodwill); for configuration files, neither because the're both awful to type in a line-oriented setting; and for protocol or file-format type things that could conceivably stand on their own and be called a 'document' (like a self-contained file at rest), XML or binary because they allow strongly typed, well-specified formats with less developer effort -- not JSON.
Trying to get that Karma up, huh? I'll bite and help you out a bit. I would think the only reason to use XML in a new project would be because it has a schema and you may need your objects "strongly typed." In days past there also wasn't very good support for JSON in C# and other enterprise languages so that extended the XML lifetime.<p>Most times you're using XML now it's to integrate with a piece of legacy software. Now that most enterprise platforms have good support for JSON, outside of a few special use cases most projects are just going to go with JSON for the convenience of it (no crazy parsers to deal with).
Both? They each have different use cases where they can be more efficient/easier to work with.<p>If you are designing a REST API, pay attention the HTTP Accept header and return whichever the client asks for.