I understand the purpose of XML, but I always hear people complain about how BAD it is? I don't really understand whats so bad about it? I usually hear the terms "bloated" and "slow" tossed around.
But I guess as programmers, what do you mainly use it for? And do you really consider it "bad"....because if it is, an awful lot of people use it for transporting of data...
Xml is great for what it was designed to be -- a platform neutral, human readable data transfer protocol with some capabilities to enforce data validation at low levels. I doubt anyone who uses Xml in this manner has a real complaint. Is it the most succint wire format? No. But there are worse options. Is it as fast as reading your custom binary format? No. But your business partners can read it in whatever stack they are using.
The problem, however, is that humans -- especially the breed known as enterprise architects -- are evil and take good things and make them bad. In the case of Xml, the early part of this century saw Xml as the universal hammer for every IT problem. Sprinkle in a little design by committee and you end up with some horrible monstrosities like SOAP and oXML. Neither of which should be wished on enemies, nevermind friends or colleagues.
XML is just a tool that comes in many flavors and uses. XML excels at some things and sucks at others. I think one of the problems is that people have seen "enterprise" XML that is needlessly complex with namespaces and crap strewn around (SOAP, anyone?). The trick to designing XML formats for humans is adding real meaning to data while not making them overwhelming to read.
One of the things people take issue with is that XML sometimes chokes on some character or some missing bracket. There is, however, both an upside and a downside even to that. The upside is that you don't have ambiguity like you have with HTML where different cases of semi-invalid syntax can be interpreted differently.
The downside is that it's a bit harder to author and harder to learn. I agree there's an argument to be made that the web wouldn't have become to big so fast if HTML was as stringent as XML, but I'd also argue that we'd be glad if it did today. :)
Also, do not use it for everything just because you can, have the sense and judgement to apply it appropriately. If all you have is XML, you tend to always be an XSLT transformation away from what you want. :)
I'd argue that the format only really matters when humans need to interact with it. If you're writing some program that serializes something and sends it somewhere where it is to be consumed by another of your programs, who cares what it looks like so long as it's as efficient as possible? Use a binary format or bunnies and unicorns for all I care.
Jeff Atwood has a pretty good blog post at XML: The Angle Bracket Tax about this if you want a source talking about it.
The most common uses I have for it are:
Services talking to each other. For example, a website using a content management system has to send some data into a customer relationship management system and this is done with XML.
Configuration storage. Web.config and app.config being common examples but nAnt scripts can also use some XML to them as well.
I don't think it is optimal but that alone doesn't make it bad to my mind.
Two reasons:
I usually hear the terms "bloated" and "slow" tossed around.
It's not the most compact syntax, but it's clearly the most expressive one. Human readable? depends on how you design your language. Most people do not design a language for XML, they just serialize objects as XML.
…why do so many people use it?
It's ubiquitous. You can query an XML database with XQuery, transform the results with XSLT as XHTML or Atom, get Atom or other XML format from other web services, get XML from users using XForms, validate it with XMLSchema, Relax NG or Schematron, process it with XProc, save it back to the database with XQuery Update. All these tools understand XML, so there's no need for mapping between different representations.
XML is not a serialization technology, it's a general purpose information set.
Here, we use it for data exchange between different systems made by different vendors with different internal representations. We build an XML transformation/interchange system to shuttle the data back and forth. It works fine for that.
XML is not inherently bad, but I acknowledge that designing a "good" solution using XML is not trivial.
In my experience, people mostly complain about the way it gets used, not the technology itself.
The bloated and slow bits that people complain about are usually the libraries/methods that are used to fetch info from it.
I use it for storing small amounts of structured information that I want to store on disk (without a database or binary serialization), or pass to another application (which essentially describes SOAP as well).
"The essence of XML is this: the problem it solves is not hard, and it does not solve the problem well." -- Phil Wadler, POPL 2003
My personal opinion is that so long as you don't care about validation, schemas, XSLTs and the rest ugly stuff and you keep the size of the files small (otherwise parsing becomes slow) you can find some good uses of XML (an example is for configuring your application instead of using INI files).
Its Good because:
Its a standard "Interface" that multiple heterogeneous systems can use to communicate with. And is "Human" Readable (kind of, try staring at 5 MB XML)
Its Bad because:
Its bloated, larger size = more bandwidth = more $$
There are other reasons, everyone has a different gripe...
Like for any other technology: there are many available tools and libraries.
I don't like XML, especially because it's funky, when people say it's human readable, they joke, I think, or have never really read an xml when one tried to embed xml in an attribute... the xml entities make it really unreadable. Furthermore, it's amazing how much space gets wasted because of the redundant end-tag, and the ability to mix free text and data...
But:
It also have the advantage of precedence, most of the times. When you're already providing web services in Xml, and one asks for a new service... it'll probably be done in Xml because that's what you know.
XML is a poor choice for files which must be maintained by humans. There is no visual separation between the markup and the content, making it hard to read. It is tedious to write correctly without a special-purpose editor. Any error in an XML document is fatal; an XML document cannot be partially processed. When an XML file is invalid, the resulting error message is often unhelpful.
For any file that must be maintained by a human, I would prefer to use any of JSON, YAML, or source code in some interpreted language (Python, Ruby, Groovy, etc.). We have found that a great way to create XML configuration for legacy code is to use the Groovy MarkupBuilder. Another good choice is to create a domain-specific language; this is quite easy to do with Ruby, Groovy, and many other languages.
Parsing is relatively easy while being human readable at the same time.
And some nice parsers ( Eg Xerces {c++} ) are readily available.
