XML and JSON are both capable of transmitting the same data, but which is better depends mostly on what you want to do with it.
This does touch on existing tooling, but you're not likely to be hand rolling parsers for either, so it is relevant.
XML
- Has better tooling for verifying schema.
- Has built in support for namespaces.
- Can be more easily restructured into HTML.
- Can be queried with XPath, which is really exceptional query language - think SQL for XML. I haven't really seen an equivalent for JSON - but I'd love to hear about it if I'm wrong on this one.
JSON
- Has significantly lower ceremony (and, at least in my experience, better pretty printers), so when a human has to look at it, it can be easier to read.
- Is, unsurprisingly, the best format when one end of the transfer is written in JavaScript.
- Has less legacy, so the chance of being forced to accept malformed JSON is lower. There is also no cultural expectation that you should have to accept malformed input.
Because one is capable of storing anything that can be stored in the other, usability and tooling is about the only criteria that is useful for comparing what it's like to use them.
If all that were wiped away, I'd probably use neither, and transmit the data as chunks of Lisp.
It's lower ceremony than JSON (barely), much easier to transform than XML, and easier to write a parser for than either (which I'd have to do if all the tooling were gone).
Storing the configuration of the program externally allows you to avoid needing to recompile the program when something changes. Switch from databaseA to databaseB? Modify the property file rather than modify the hard coded values and recompile from source.
What's more, Java offers a class as part of its standard runtime environment that facilitates this - the Properties class. This class can either take a .properties file or an .xml file that matches the dtd specified at http://java.sun.com/dtd/properties.dtd (it really is a rather simple one - its the same as the one in the javadoc).
With the Properties class, you load it in, and then you can easily call getProperty(String key) or getProperty(String key, String defaultValue) and get your values out of it. This is much easier than loading values from a custom xml file and all the xml or xpath processing that you would have to do with it. Furthermore, its a known thing and easier to get right.
That's the property file.
access.extensions = accdb,mdb # where you might find an access database
And then you've got the corresponding bit of Java...
String[] extensions = prop.getproperty("access.extensions", "accdb").split(",");
for reading it out. This makes the code a bit more self documenting, a safeguard against not having the file with a default value.
If you really wanted to use xml instead of a properties file, it would look like:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd">
<properties>
<comment>Access Database Extensions</comment>
<entry key="access.extensions">accdb,mdb</entry>
</properties>
But again, the key point is to move the values out of the code and into external files that are easier to work with. And Java already has the tools for reading those back into the system.
Best Answer
XML has two very important attributes that make it attractive for data transfer between heterogenous systems:
If you're looking for something less verbose that still has both of these attributes, you can try using JSON.
If you're simply transferring data between two homogeneous databases on the same network, there are probably easier ways. For example, Microsoft SQL Server has at least three different ways to transfer data between databases: Bulk Insert, SSIS, and Replication.