Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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...

share|improve this question

closed as primarily opinion-based by gnat, Kilian Foth, Dan Pichelman, MichaelT, GlenH7 Apr 8 at 19:24

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

13 Answers 13

up vote 57 down vote accepted

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 man -- especially the breed known as enterprise architects -- is evil and takes good things and makes 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.

share|improve this answer
7  
+1 - anyone who has ever had to deal with EDI just wishes XML had been invented before that mess came about. –  Scott Whitlock Mar 23 '11 at 17:46
7  
+1 Matches my thoughts almost exactly. I'd only add that for storing plain and simple data, even if it's a hierarchical (but not too deeply, that doesn't blend well with anything), there are certain formats that work just as well - most notably JSON and YAML. The latter is imho awesome with regards to human readability. –  delnan Mar 23 '11 at 18:01
5  
To paraphrase jwz: "There's a certain kind of programmer who'll look at any problem and say, 'I know, I will use XML.' Now he has two problems." –  Adam Crossland Mar 23 '11 at 18:23
4  
Please tell me oXML was intended as a joke, like Brainfuck or Whitespace or LOLCODE. –  dsimcha Mar 23 '11 at 18:32
4  
@Shamim Hafiz, SOAP is definitely among the worst monstosities ever bred by the mankind. –  SK-logic Mar 24 '11 at 10:48

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.

share|improve this answer

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 are however both an upside and 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 argument that we'd be glad if it did today :)

Also, 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, sends it somewhere where it is to be consumed of 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.

Pros of XML

  • Covers a lot of edge cases that YAML and JSON don't
  • There are excellent tools for parsing and validating XML in an array of different platforms and languages
  • XML can easily and powerfully be transformed into another format (through things like XSLT)
  • Reasonable xml documents are simple for humans to read and edit, don't tell me JSON is easier, it isn't :)
  • XML is self-describing to some degree, ie it directly contains information about it's structure and meaning (in contrast to most binary formats)
  • Handles encoding
  • They are whitespace agnostic which makes for easier cross-platform use
  • Breaks if it isn't wellformed (Ensures data is structurally correct)
  • It's not SGML

Cons

  • Verbose
  • It's not as fast to parse as binary
  • Breaks if it isn't wellformed (crashes your application)

Good uses

  • Configuration files
  • Data interchange formats
  • Version resilient fileformats
  • Storing documents in databases

Not so good uses

  • Data transfer formats
  • Serializing Objects
  • Storing relational data in databases
  • Fileformat for high performance I/O scenarios
share|improve this answer
3  
I doubt that "configuration files" should be under "good uses". They aren't data, rather instructions. –  daknøk May 3 '12 at 9:44
    
I am with @daknøk here - I can't count the times I had to spent huge amounts of time figuring out a configuration bug in a hunderds of lines long XML-file that specifies the dependency injection, that was based on one small typo in an XML-attribute. –  Gjallar Oct 27 '12 at 10:32
1  
If bad data crashes an app then is it the data that has a problem? –  James Snell Jun 11 '13 at 17:03
1  
Any file format that is malformed/corrupt has the potential to crash broken software. So XML is not the culprit here... just your application. Otherwise, good post. –  Thomas Eding Apr 7 at 21:18

Two reasons:

  1. There are an awful lot of bad programmers out there. XML may be bad, but it's also simple (on the surface at least) and makes it very easy to write bad software. Sorta like VB.
  2. A lot of the people making these decisions aren't programmers, but business types who have only heard that "everyone's using XML" and so they decide they want their product to use XML too.
share|improve this answer

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.

share|improve this answer

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).

share|improve this answer

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.

share|improve this answer
    
... and we ask ourselves for years why for chrissakes SOAP has been built upon XML. –  JensG Apr 7 at 18:59

"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).

share|improve this answer

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...

share|improve this answer
3  
@Darknight: I challenge the human readable by throwing Xml Entities at you... (personal peeve) –  Matthieu M. Mar 23 '11 at 17:51
    
Xml Entities.... shudder eeeeeeeuw –  Darknight Mar 23 '11 at 21:34
1  
I don't think XML is inherently bloated - but implementations of it are. I find XML-RPC to be particularly egregious at unnecessary bloat. –  HorusKol Mar 23 '11 at 22:18
1  
@HorusKol: <advanceAcceptanceIndicator>Y</advanceAcceptanceIndicator> The ratio data/markup is so low... I call this "bloated". JSon, for example, would be only as half bloated: advanceAcceptanceIndicator: "Y". There is also the fact that text between tags is valid, so when reading Xml, you need to decide what to do with this cruft \n\t\t\t, and the solution is generally to just ignore it, because you were never really interested in this to begin with. –  Matthieu M. Mar 24 '11 at 7:15
    
@Matthieu M.: A better tag for boolean value would be: <advanceAcceptanceIndicator />. Now don't get me wrong - I am not an XML zealot - I use JSON just as much, but sometimes XML is the choice to make. –  HorusKol Mar 24 '11 at 22:11

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:

  • Xml can be specified (xsd) and tools are available that check the conformance of Xml data
  • lots of tools (text editors and the like) support Xml
  • lots of libraries (in about every programming language) support Xml

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.

share|improve this answer
2  
XML is more readable than binary or position- or comma-delimited data. –  FrustratedWithFormsDesigner Mar 23 '11 at 18:00
    
Only for a naive user. If I have to visually scan a couple hundred records looking for one that's missing some data I'd much rather look for some blank columns in a block of fixed-length records than wade through a morass of elements and attributes looking for an empty tag. –  TMN Mar 23 '11 at 19:12
1  
@FrustratedWithFormsDesigner: it really depends on the data at hand. Xml embeds the nature of information near the information proper. If you look at functional programming languages you'll see things like (Haskell): data Person = Person { surname :: String, firstName :: String, age :: Int }, if I then see Person "Doe" "John" 42 it is readable too, and avoid a lot of cruft, yet it's closer to comma delimited. –  Matthieu M. Mar 23 '11 at 21:01
1  
Ok, Your example was easier to read without the markup, but trivial (I'd say less than 8 or 9 data elements) examples can be made to support all forms (except maybe binary). Datafeeds from the mainframe originate as position-delimited strings (and most of it is just numeric codes), and they are much easier to read and debug and manage after being transformed to XML. Like you said, it can depend... –  FrustratedWithFormsDesigner Mar 23 '11 at 21:22
    
@FrustratedWithFormsDesigner: Yes, that's exactly my point :) It depends, but because there's such a rich ecosystem for XML, and because it's easier to only maintain one set of tools/libraries, people usually use XML for everything. Personally, I favor JSon over XML, but once again without indentation, it's messy :p –  Matthieu M. Mar 24 '11 at 7:12

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.

share|improve this answer
4  
I think you're missing the point of XML, the markup is content. The purpose of XML is to describe the meaning of your data. For instance, if you have a telephone number, tagging it as a landline number or mobilenumber adds context that other's might use. Or adding a phone tag around text at all for that matter (might make that number callable on a mobile phone). As for your other points I disagree as well. Authoring xml documents is usually pretty straightforward. Error messages are always related to wellformedness and I'll take editing xml by hand over JSON any day –  konrad Mar 24 '11 at 2:52
    
@konrad your phone example would be valid for HTML. –  Florian F Sep 13 at 21:49

Parsing is relatively easy while being human readable at the same time.

And some nice parsers ( Eg Xerces {c++} ) are readily available.

share|improve this answer
    
Well, it's easy as long as the documents are small. If you have to parse documents too large to reasonably fit into memory, then things get grim. –  TMN Mar 23 '11 at 19:01

I would say that every project chooses the standards that fit best the philosophy of their tools and the people that build it.

And that philosophy and the tools change over time.

Regarding your question, mass is no proof of quality. And I am not arguing about the quality of xml here, I think any decision can be justified.

Probably it was chosen and pushed forward because it was there at that time when it started to gain momentum.

Many alternatives were invented later or their qualities were understood later. In software design theory there is a rapid development of guiding principles.

Principles like maintainability, readability by humans, simplicity, don't repeat yourself, they become more and more clear, but some years ago they did not seem so important.

But xml is now baked in so many applications, brains of developers and managers and into their habits, so it will probably take much time until alternative standards can spread to a similar amount.

Maybe it can only be swapped out in the process of swapping out generations of applications and developers. There is no judgement in this, but you asked for it :)

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.