Is XML considered harmful?

Question

The title of the question pretty much says it all. But these are the keypoints that I am interested to find out, and they are just totally random in my mind:

1. Does it it make your job as a developer easier or harder?
2. Does it make you more or less productive?
3. Parsing with a DOM parser requires more memory to hold the entire structure of the document. Does this encourage to use a SAX parser, which I believe is a little harder to use?
4. In cases where XML is being used for configuration or as declarative programming, what are your positive and negative experiences?

Answer 1

1. It's a tool. It only makes life harder if used improperly. Use the right tool for the right job and it'll almost always be beneficial.
2. See answer 1.
3. See answer 1.
4. XML for config can be absolutely fine. I've seen it used sensibly for normal config, Spring Dependency Injection, state models, mappings etc. When used properly, it's great. I've seen it used badly for the same things (though the horrible state model xml, with embedded javascript, I've seen is particularly notable).

Answer 2

1. Easier, much easier. I can focus on solving business problems rather than being a hero that's reinventing the wheel of structured data storage.

2. More productive. It is trivial to hack together a quick XML schema where needed. And with LINQ you can perform queries stupidly easily.

3. I usually use a forward-only reader if the file is likely to be large or where performance is needed. Otherwise a simple XmlDocument object in .NET suits me for the other cases. Or, of course, there is LINQ.

4. In many situations I do not like .NET .config files. Especially when they are used to setup, declaratively, very intricate details of the program which the user has a 0% chance of being interested in or wanting to modify. I prefer this type of stuff to exist in the codebase. I like .config files to be used for stuff that the user is likely going to change. But that is just me!

Answer 3

Since XML essentially provided a standard format and associated tooling as an alternative for the ad-hoc encodings and user-defined data formats that people used to do before it, I don't think it can be considered harmful compared to things that came before it.

I feel that being able to deal with information that is encoded sensibly, whose structure can be validated, and for which there is standard tooling, definitely made me more productive. Is it costly in space and memory? Yes, but space is cheap, the information is highly compressible, and I usually don't parse huge portions at a time. If I had wrote my home-grown formats and parsers it would have been less efficient.

Also, with tools like apache-digester, I rarely ever have to actually see a tag before I get my object.

As for bad experiences, I would say that bad schemas and formats are a problem, and would also say that the need to encode/decode strings for HTML-style compliance adds a little work.

Answer 4

I don't 'love' XML, but I would have to say it makes my job as a developer easier. XML is well known and there are plenty of mature tools and APIs to manipulate it. If you are going to store configuration settings or pass data as text, why not use XML? It is an industry standard.

Answer 5

One advantage is the human readability. 50 years from now people can still read XML-documents. You can use it for archiving data that needs to be stored for decades (legal requirements).

Can data in MySQL still be read 50 years from now?

Answer 6

Depends. Does "sometimes it's a pain in the ass" count as harmful?

The thing with XML is that it provides a useful general format with one specific special property: it's got a clear morphism into markup languages, so that an XML data set can be transformed into something that can be easily displayed. Parsing it is not too hard, and at least it is a standard, but in many cases what people use it for could be better done with YAML, or even Lisp S-expressions, which are even easier to parse and even more standard, being as they're defined mathematically.

Whether to use DOM or SAX is really a matter of whether its easier to do what you want "on line" or if you'll need multiple passes. An XML re-indenting tool is a perfect example of something that can easily be done using SAX -- you just count the number of begin tags you get to maintain the indentation, and decrement it again at the end.

On the other hand, if you will need to access the data randomly, say in a parameters doc or something, DOM is better, because you read it once and for all.

In most applications, other than, say, an embedded system, keeping it in memory is not usually an issue; documents are usually not much over 10K bytes anyway. Of course, if your application is forcing you to deal with asingle multi-gigabyte XML file, that might not be appropriate for you.

Answer 7

Jeff Atwood had a post about XML-as-tag-soup a while back, but I can't say I agreed with it. XML isn't perfect, but considering what we've been able to do since its emergence, I'd say it's a good thing.

Answer 8

I try to avoid it when possible. There is the idea of "programming in XML" which to me makes a project too confusing for new developers coming in. When there are 100 places to look for things between source files and XML files it becomes problematic.

In Java, for example, I much prefer annotations to working with XML.

Another example, in the Cocoa framework with Objective-C, one thing a lot of people are doing now is passing around binary plists for data instead of using XML, because it's too slow to parse.

It all depends on the situation, but I think too many things in the past 10 years were architected with XML in mind, but they could have been thought out a little better.

Answer 9

1) Quite often it makes life harder. In a lot of cases in the java world, you end up building a parallel structure of abstractions inside your xml files: Two classes can reference each other as part of the code hierarchy, but also in the xml hierarchy. This quite often means there is a separate form of naming/adressing scheme being built inside the xml file; this often exists beacuse of the xml.

2) Well formed code alternatives make me more productive.

3) Dont know/dont care

4) If xml only mirrors code artifacts I think it's better done in code, annotations are good.

Answer 10

XML is not an end in itself; XML exists to provide a format to exchange (structured) data between programs. As such, the question is similar to "Is ASCII considered harmful?".

Therefore if a program needs to exchange structured data with other applications, I would recommend XML, given that there is decent support for XML in your programming language.

As for configuration files: .ini is a mess, registry is a mess, .conf (or whatever) files are a mess, and XML is structured mess, with angle brackets. (But if your editor knows how to read XSDs for your config files, it may be a bit of a help)

Answer 11

I consider it mostly harmfull. Not by itself, but by how it is used.

XML was invented as a way to bring structure to the web while retaining the unstructuredness of HTML. Think of data combinded with some text, markup, and style, delivered to the browser, yet still perfectly machine readable. I have seen too little of that.

XML, however, is used for lots of stuff where it kind of works, but which it is not the ideal tool for. Think of SOAP: I can think of three human readable, textual representations that are easier to parse and easier to read than XML: YAML, Lisp's s-expressions, and JSON. Why anyone would build a RPC mechanism on top of XML is beyond me.

As for configuration files, I am undecided on that one. With a Unix background, I absolutely hate writing XML-based configuration files. On the other hand, it makes sense to use XML if there is a GUI-tool as well. But the same argument as in the last paragraph applies: Configuration needs structure more than free-form and there exist better approches to structured textual representations.

To recap: XML is about combining structure with free-form. It's cool if you need both. If you need structure only (and most current uses of XML fall into that catagory), you need to use XML-Schema to make the free-form aspect go away. Yet when you later write the free-form free XML, you are likely to commit syntax errors, because XML has so little, well, structure.

Then there is the political aspects: Because XML is the standard, it is often forced on you, even though you know it is not the optimal tool for the job. But it looks incredibly good on Powerpoint and therefore the suits love it. So it is likely to spread to ever more areas of IT.

So to answer your questions:

1. Mostly harder
2. Mostly less productive, because in is still alien to many host languages
3. Depends
4. Refer to the paragraphs above

Answer 12

The flexibility of the XML namespace beats all its misgivings. The Podcast XML is built on top of the RSS document type, the Feedburner tweaking is built on top of the type also without losing any meaning of the original RSS document. Would you like to extend RSS 2.0 and call it RSS 3.0? No one would allow that. "Hey, use XML namespace!"