40

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

  • 1
    Your answer is in the question. People still use it because people used to use it, and the options are (1) rewrite all the code that used it before JSON and YAML, or (2) suck it up and do the stupid thing. A lot of people still perpetuate cycles of violence, too. That doesn't prove the inherent worth of the practice. – Parthian Shot Apr 27 '15 at 01:45
  • 6
    Try JSON for an actual document (man page, Knuth, Hamlet, etc). You'll then understand why XML is essential. This is a space where JSON sucks (go ahead, try). Using either one in the other's design space is questionable. The problems from using XML in JSON's space are mainly verbosity and speed, while the problems from using JSON in XML's space tend to involve portability (try to interoperate with a friend who did a book in JSON, but their own way), integrity, and interpretation problems that require lots of human effort to fix. Use the right tool for your job. – TextGeek Oct 08 '15 at 22:15
  • 1
    XML is only bad because many people abuse it for things out wasn't designed for. If you don't need your data to be readily extensible (i.e. the scheme is used by multiple parties who need to interoperate, rather than centrally dictated by one authoritative party), and if your data isn't a document (i.e. if DOM would've been a poor abstraction of your data), then XML isn't suited for those applications. When your problem domain falls under what XML is designed for though, nothing else matches XML. JSON, YAML, etc are poorly suited for the space that XML really are designed for. – Lie Ryan Mar 27 '19 at 03:37

12 Answers12

95

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.

Nevermore
  • 103
  • 4
Wyatt Barnett
  • 20,685
  • 50
  • 69
  • 16
    +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
  • 1
    @Scott: if EDI measn EDIFACT, I use it daily, and mostly prefer it (`Y – Matthieu M. Mar 23 '11 at 17:54
  • 12
    +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. –  Mar 23 '11 at 18:01
  • 2
    @Matthieu M.: I think Scott is talking about the insane hodgepodge of electronic data interchange formats one had to deal with in the last century before there was a minimal lingua franca such as XML. – Wyatt Barnett Mar 23 '11 at 18:02
  • 12
    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
  • 14
    Please tell me oXML was intended as a joke, like Brainfuck or Whitespace or LOLCODE. – dsimcha Mar 23 '11 at 18:32
  • @dsimcha: it wasn't. Meta meta programming was hawt. – Wyatt Barnett Mar 23 '11 at 18:40
  • so SOAP is a monstrosities????? – Shamim Hafiz - MSFT Mar 24 '11 at 08:35
  • 10
    @Shamim Hafiz, SOAP is definitely among the worst monstosities ever bred by the mankind. – SK-logic Mar 24 '11 at 10:48
  • 2
    Also, for some reason, every XML library is always unnecessarily complicated to use. The format itself isn't even that bad. – sudo Feb 16 '18 at 19:14
  • In the GUI world, I think XAML (WPF) is horrible. QML is a better language. – Aminos Sep 22 '22 at 13:57
27

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.

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, i.e. it directly contains information about its structure and meaning (in contrast to most binary formats)
  • Handles encoding
  • Whitespace agnostic, which makes for easier cross-platform use
  • Breaks if it isn't well-formed (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 well-formed (crashes your application)

Good uses

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

Not so good uses

  • Data transfer formats
  • Serializing Objects
  • Storing relational data in databases
  • File format for high performance I/O scenarios
Air
  • 103
  • 5
Homde
  • 11,104
  • 3
  • 40
  • 68
  • 14
    I doubt that "configuration files" should be under "good uses". They aren't data, rather instructions. – daknøk May 03 '12 at 09:44
  • 3
    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
  • 3
    If bad data crashes an app then is it the data that has a problem? – James Snell Jun 11 '13 at 17:03
  • 5
    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 07 '14 at 21:18
  • 2
    @daknøk So what do you propose instead for configuration files? Configuration files aren't data? That's funny. So you call attribute such as window size an instruction? – mip Mar 07 '16 at 23:29
  • 3
    Could you expand on "Covers a lot of edge cases that YAML and JSON don't."? – Trevor Hickey Jun 15 '16 at 15:12
  • 1
    I'm really struggling to think of edge-cases where XML can solve the issue over JSON. Would someone mind giving me some links to learn or maybe an example? In my mind, I'm almost sure there's a way to work around the edge cases with JSON, right? :\ – Jim Feb 01 '17 at 18:40
  • You missed "everything is text" in Cons. – Beefster May 01 '18 at 21:47
  • 1
    @TrevorHickey: No, JSON doesn't support namespace, which is crucial for interoperability and extensibility in an environment where there's no central authority to dictate what everyone does. Namespace allows designing vendor extensions without breaking anyone that doesn't understand the extension. Second, JSON is also poorly suited for documents format, i.e things that aren't hierarchical objects. The XML model is annotated texts, trying to do something similar in JSON is really awkward fit. – Lie Ryan Mar 27 '19 at 03:48
14

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.

JB King
  • 16,795
  • 1
  • 40
  • 76
11

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.
Mason Wheeler
  • 82,151
  • 24
  • 234
  • 309
  • What an absurd and totally useless points. 1) XML is far from bad and it has absolutely nothing to do with the quality of the software people write whether they choose it or not, I've seen quite good VB programmers, implying that if you use VB you actually write bad software is just silly because there's a complete disconnects between how you write software and with what you use to write it. 2) Yet another false assumption, choosing XML is great and most of the people that are choosing it for better or worse are certainly programmers. XML isn't silver bullet but it's good for certain things. – eyalalonn May 27 '16 at 01:50
  • 2
    @EyalSolnik: Some people, when presented with a problem, think “I know, I’ll use XML.” ` Now they have many, many more problems ` – Mason Wheeler May 27 '16 at 10:45
  • 4
    Just because people abuse something doesn't mean the technology itself is bad, you can see the same syndrome in many places. – eyalalonn May 27 '16 at 18:46
10

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.

Max Toro
  • 316
  • 1
  • 11
  • 1
    ... and we ask ourselves for years why for chrissakes SOAP has been built upon XML. – JensG Apr 07 '14 at 18:59
  • Verbosity = redundancy = error correction = readability = robustness in the face of noise/decay/human-error. Not such a bad thing, imho. – TextGeek Aug 23 '23 at 15:24
7

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.

FrustratedWithFormsDesigner
  • 46,105
  • 7
  • 126
  • 176
6

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

Steven Evers
  • 28,200
  • 10
  • 75
  • 159
5

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

sakisk
  • 3,377
  • 2
  • 24
  • 24
  • Otoh, if you "don't care about validation", your code and data will not be very robust. Maybe being able to check if the data is corrupted is "ugly stuff", but I for one want it. Also as noted already, good luck doing documents in JSON etc. Got a better solution for *that* problem, not the problem JSON aims at? – TextGeek Aug 23 '23 at 15:27
  • There are better and more compact ways of doing validation. For example avro and protocol buffers. – sakisk Aug 24 '23 at 18:43
2

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

Darknight
  • 12,209
  • 1
  • 38
  • 58
  • 4
    @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
  • 2
    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
  • 3
    @HorusKol: `Y` 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 07:15
  • @Matthieu M.: A better tag for boolean value would be: ``. 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
  • 1
    @HorusKol: It would, but I never said it was a boolean value, it just happens to be a single char :) The use of attribute here (`value` ?) would probably be superior too, because people could be tempted to insert whitespaces between two tags. – Matthieu M. Mar 25 '11 at 07:31
  • 2
    "Its bloated, larger size = more bandwidth = more $$" I guess compression hasn't been invented where you are yet. – Andy Jul 18 '17 at 01:16
  • Re. bloat: I've done extensive experiments applying CSV, JSON, XML, and other formats to various data topologies -- in all but the most simplistic cases (such as data that fits CSV well), competent XML is competitive, and very commonly more compact than JSON. And unlike readability, validation and other factors, the verbosity of data shrinks in importance at the rate of Moore's Law. – TextGeek Aug 23 '23 at 15:37
2

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.

Matthieu M.
  • 14,567
  • 4
  • 44
  • 65
  • 6
    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 07:12
  • The example of "embedding XML in an attribute" is indeed ugly -- but it's not really XML. By definition (which I helped write), if something is inside an attribute it's an XML string literal, not XML. It's like how ugly C gets if you hand-pack objects or C code into arrays of floats, or JSON if you put JSON inside a quoted string, or any similar case. Yup, you can misuse XML and it gets way ugly; also true of almost any tech, and especially of using *syntaxes* to contain themselves. – TextGeek Aug 23 '23 at 15:33
-1

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.

kevin cline
  • 33,608
  • 3
  • 71
  • 142
  • 9
    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 – Homde Mar 24 '11 at 02:52
  • @konrad your phone example would be valid for HTML. – Florian F Sep 13 '14 at 21:49
  • "Any error in an XML document is fatal; an XML document cannot be partially processed." Yes, that's a large par to the point of XML. – Andy Jul 18 '17 at 01:20
  • @Andy It's pretty useless if the XML was written by the human and the application just says "wrong!". A human editor needs to know the line where the error was detected. – kevin cline Jul 26 '17 at 03:15
  • Any number of tools tell you exactly what line and often what character the error is detected on. XML Tools in NotePad++ for example. .Net will tell you exactly where your .config file is wrong too. If you're talking about an API, one of the benefits of XML is that the API developer can also provide an XSD, which besides ensuring valid XML syntax can also tell you if you have any elements that don't belong, if there should only be one of that element, etc. Handwritten json is much easier to screw up. – Andy Jul 26 '17 at 21:39
  • If you don't like that XML parsers stop at the first WF error (as do almost all modern compilers, btw), then write an "XML--" parser that doesn't do that. That should take you a few hours, esp. if you start from an existing parsers (available in just about any language you like). Or just run "tidy". In contrast, try tracking down a misplaced brace in JSON, esp. with few to no validation tools. – TextGeek Aug 23 '23 at 15:42
-2

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

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

Simon
  • 425
  • 3
  • 6
  • 2
    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'd question the human readability part. It just takes way too much effort to read XML over reading an equivalent JSON. – cmaster - reinstate monica Mar 27 '19 at 07:17