XML was designed to be a be-all end-all data format. However there have been issues that have arisen from its use.
Strict Implementations
I’ve seen more than once where companies requesting data be sent via XML were really just text parsing a file. They’d require nodes that were not being used, and not having the node would cause the file to not load into their system.
This clearly doesn’t keep with the idea of XML, and can cause a lot of unnecessary overhead.
Unnecessary Overhead
In addition to having to load in multiple unused nodes like in the previous example, some people find that the opening and closing of tags causes the self descriptive nature of XML to take up as much, if not more, space than the data itself.
When there is a lot of data being processed and sent, it can mean that a lot of wasted bandwidth is being used, or abused if you would prefer.
This is made worse because each tag has to be defined and used.
Wasted Resources/Performance
With the overhead, you don’t just waste bandwidth and storage space. Most XML parsers are not really efficient with their handling of memory. They either try to load the entire memory into memory, and then deal with the loading of the nodes and memory overhead of keeping a large tree, or they have to parse on the fly, at the sacrifice of performance.
Both of these sacrifices are bad, especially if you are processing lots of files.
If you are generating them, it isn’t as bad, since you can generate a file on a schedule, and just have people download the static file. Sure it may be “out of date” by a few minutes, but that’s not too bad all things considered. Depending upon how frequently a file gets updated, you might see and update schedule that’s every five (5) minutes, every hour, once a day, or even less frequently.
Even if the file takes a while to create, if it’s done on a schedule and not real time, it improves the overall performance – usually worth it unless you have to have real time data. Especially if the other option was to have it generated each time it was requested, and that might happen hundreds of times a day, or even an hour depending upon the data and it’s popularity.
Special Characters
If you are using an XML tool to build your file, this shouldn’t be as big of an issue. However, it can be, especially if you are writing it on your own.
Since XML uses tags, there are some characters that must be encoded to ensure it’s not improperly parsed, such as the angle brackets, ampersands (&), and a few other characters.
There are ways to encode them, but failure to do so correctly, could mean parsing errors.
Problems with XML was originally found on Access 2 Learn
