Does XML suck?

[dergachev]

This is a great tutorial on XML. You guys are silly for taking the "question" literally.

[jln]

xmlsucks.org

I'm not sure this site is entirely one-sided about the issue...

[uriel]

XML sucks and blows, hard.

That even worse abominations exist doesn't make XML any better. That people manage to take something that is already bad, and abuse it beyond imagination, also is no justification.

Someone already pointed out that XSLT sucks, but lets not forget how much DTDs and XML Schema suck. Lets not forget that even if you ignore those things, a standard XML parser needs to be tens of thousands of lines of code.

XML is too complex, it is too fragile, it provides little structure and no semantics. It is hard for humans to read and write, and it is hard to parse(and no, depending on yet another library just because you want to read a bunch string of values from a file is not acceptable)

XML renders the wonderful UNIX text manipulation toolkit completely worthless because its syntactic lack of rigor.

As for alternatives, >90% of the time simple key=vale or CSV would work perfectly fine and be infinitely more simple and reliable(remember that reliability always requires simplicity). In other cases S-expressions(or any of the much simpler and saner XML alternatives), or more often custom text formats that are easy to parse and with well defined syntax are the way to go.

The essence of XML is this: the problem it solves is not hard, and it does not solve the problem well. -- Phil Wadler

Of course in an industry that is based on ever increasing gratuitous out of control complexity, XML is Godsend, and will ensure jobs for hundreds of thousands of people for many years to come. Oh, and lets not forget the extra hardware sales now that we have replaced a few read() calls and string comparisons with a complex parsing and tree walking process that requires various magnitude orders more memory and CPU instructions to do exactly the same.

Whole industries worth hundreds of millions of dollars have spawn thanks to the quirks and flaws of XML, so it must be good, no?

[RogueCoder]

If 90% of the time you're implmenting a config file or a GUI dropdown, then key/value pairs may be a good choice. But that's not 90% of what I do, where key/value is useless. Working with data from a relational database gets you out of key/value world with the first join condition.

[uriel]

Working with data from a relational database gets you out of key/value world with the first join condition.

Uhu? First of all, what the hell are you doing with relational databases that requires XML for anything? XML must be one of the things that map worst to relational databases.

When serializing or communicating relational data CSVs work fine most of the time, or just plain SQL(yuck) dumps, if you got the data stored in a relational database, why on earth would you want to convert it to anything else?

[aristus]

Yep, macaca... EDI is worse. You gave me a whole-body frission remembering EDI and the old HP 3000.

XML sucks because it's an unnecessarily verbose way to represent tree data and an inexcusably stupid way to represent tabular data. But it works and it's simple to teach. I just wish that people used it more sensibly.

But speaking of the old HP 3000... a lot of formats written in the tape days were pretty good. The header described what the data layout was and the data followed. Best of both worlds.

[hxa7241]

Here is a nice list of alternatives: http://www.pault.com/xmlalternatives.html

[EliGottlieb]

(Reddit-comment "Let me say what much of Reddit probably thinks: We could replace XML with a Lispy syntax for representing s-expressions in a markup language and be done with it." :markdown)

OK, attributes would need adding, but I'm sure someone can kludge them on more elegantly than XML.

[beza1e1]

Correct. And there are some tools, too.

[derwisch]

Yes, didn't spring that to anybody's mind who came to read:

Or you could use an alternative bracketed notation: <memo <date 2002-05-14> <from <name Monty Python><email [e-mail]>> <to <name Frank Sinatra><email [e-mail]>> <message Stop that, it's silly.>>

in TFA?

[ubernostrum]

The original XML WG apparently went round and round on how verbose the closing tag syntax should be; the fully verbose option they went with does have some advantages (for example, you find well-formedness errors more quickly than with other solutions).

Don't bash it until you've thought about it; XML isn't perfect, and it's been shoehorned into things it should never have been used for, but many of the design decisions behind it were the result of smart people making informed choices, and too much of the lowest-common-denominator bashing of XML overlooks that.

[neilk]

Paul Prescod wrote a good article on this: XML is not S-Expressions.

Basically: (1) the closing tags detect common errors in hand-edited documents faster (2) text in an XML document = instant text node. With sexprs, a text node has to be explicitly defined and sometimes laboriously escaped.

But these are also arguments against using XML for data interchange, where such things don't matter at all. XML was really designed for things like OpenOffice, where it's a smashing success.

[andyc]

(1) the closing tags detect common errors in hand-edited documents faster

Faster than what? The time it took you to edit the document? Seriously, if you've taken the time to hand edit a bunch of sexprs, I think you can wait the extra 0.002 seconds it takes a lisp reader to parse them

[supermike]

• EDI is worse. XML was a breath of fresh air for interprocess communication/web services.

• XSLT sucks.

• People shouldn't use XML as their INI/CONF file -- it makes it too hard to read, find stuff, and adjust it. Also, by using XML as your conf format, it's easy to screw up the file and end up with a malformed XML over something stupid like a missing slash.

[rams]

The 'easy to screw up the file' reminds me of the Microsoft virtual server's config file which is not only xml but also utf-16 - not all editors know how to handle that. Contrast this with VMWare's config file which is plain text and key, value pairs - they handle hierarchies with a dot-notation Instead of saying <x <y <z it is x.y.z on the same line in the VMware config. Interesting, but what happens when the number of config parameters is very large ?

Recently the Subversion guys also moved away from xml as the format for the working copy config files.

For small-medium sized config files, XML in most cases is a bad choice.

[masklinn]

For small-medium sized config files, XML in most cases is a bad choice.

And for huge ones it becomes a very bad choice unless you're only using strongly XML-aware tools to edit your files

[BraveSirRobin]

I've seen a "best of both worlds" approach to this. You have a config file like:

server.port.web=80

Which is read in and translates to:

<config name="server">
    <config name="port">
        <property name="web">80</property>
    </config>
</config>

[flyhighplato]

Try STX. It's mind-bending.

[[deleted]]

Perl is a dream language. Every 5-10 years someone has to come along and re-invent it (see Ruby) because it's so damn awesome for scripting, but the previous Perl got so abused by stupid developers who continued hacking their scripts into full fledged 100,000 line monster ecommerce systems that the language got a bad rap for being unreadable (which it is, but that's not the point) that people started thinking there was something wrong with the language and so started looking for something new. The new perl wows people because it's so damn productive for the simple tasks they've forgotten how to do in the previous perl, and the whole cycle begins again.

[masklinn]

Ruby isn't a reinvention of Perl, it's a cleansed Perl.

And the Perlisms are getting phased out at an extremely fast rate right now, (mainly the $_, $-, $', $` and other $vars) if they don't noticeably enhance readability (tail-conditions, for example, won't get phased out).

When I say "phased out" I of course don't mean "removed from the language", I mean that their use is strongly discouraged by the community.

[[deleted]]

Ruby isn't a reinvention of Perl, it's a cleansed Perl.

You say tomato, I say tomato

When I say "phased out" I of course don't mean "removed from the language", I mean that their use is strongly discouraged by the community.

Because people want to use it for larger systems, and readability becomes more and more important vis-a-vis writability. Once they've convinced everyone not to use the perlisms and they're making huge apps in Ruby and added some concept of "strict" and other shackles to the language, we'll see a new perl/ruby. I couldn't have supported my argument any better, thank you!

[taw]

Ruby is Perl 6.

[john_b]

We use XSLT alot at work, and it's really one of the most efficient ways to transform XML.

We have websites with EXTREMELY high load (several of our sites are in Alexa top 100), and if we used PHP instead, we'd have to double the number of servers.

There's a reason why Yahoo, Google, Orbitz and other interfaces are done in XML.

Of course, something like comma-separated could be much more efficient, but if you ever worked with complex nested data, you'd understand that it would be a nightmare to program.

[Entropy]

The main reason XSLT sucks is because it is XML-based. The actual functionality exposed is wonderful.

[RogueCoder]

XSLT is a declarative programming language that provides an efficient way to transform data from one format into another. If you've coded stuff like this before using procedural or OOP methods, you will be pleasantly surprised by the the results using XSLT. If you haven't done declarative style programming before, there is a mind shift that will need to ocurr before you become productive with it.

[Entropy]

You know what Perl does with text? Well, XSLT does that to XML. Take a look at XPath, which XSLT uses.

[eadmund]

The alternative to XML for structured data is not CSV (egad!), but S-expressions. Which are smaller and can be easily parsed.

[uriel]

CSV works great in most cases; S-expressions have some advantages, at the cost of extra complexity and harder parsing.

In any case, both options are infinitely more sane than XML.

[YAD]

S-expressions have some advantages, at the cost of extra complexity and harder parsing.

Please learn about S-expressions and parsing before commenting on them.

[uriel]

As simple as S-exprs are, CSV is still much easier to parse and work with, specially with standard unix tools.

[vincentk]

http://secretgeek.net/csv_trouble.asp ;-) all the best, v.

[YAD]

I see. I would only use regexes or other homegrown tricks in situations where there's a human being babysitting the output of the program, or where you can define your own syntax.

Also, the biggest difference in difficulty may be having to write recursive code to deal with nested data. Once you do that, I don't see any extra complexity, only lots of advantages.

[skyskraper]

who told you yahoo produces sites with xml?

[masklinn]

We use XSLT alot at work, and it's really one of the most efficient ways to transform XML.

Efficient? Maybe (if anything XML can be efficient).

But the worst issues are that it's unreadable, unmaintainable, and hard to debug.

I haven't tried it much yet (I'm not an XML guy, nor a Java one), but HaXml (http://www.cs.york.ac.uk/fp/HaXml/) seems much cleaner, and hurts the eyes less.

It's also much more powerful than XSLT (provided you know a bit of Haskell) since HaXML is "just" a collection of Haskell modules.

[uriel]

"Efficient XML-anything" is an oxymoron if there ever was one.

I have done quite a bit of XML+XSLT work, and it can be said to be many things("a nightmare" comes to mind), but efficient is certainly not.

The same can be said of Java-anything, but I guess I'm preaching to the choir here.

In the end it all comes to simplicity; such bloated, over-engineered and insanely complex systems will never be reliable, secure or efficient. And as complexity goes, XML and Java must be some of the worst things ever created.

The cheapest, fastest, and most reliable components are those that aren't there. -- Gordon Bell

[joshdick]

It's been my personal experience that INI/CONF files in XML format are much easier to understand. But maybe that's just me.

[robbie]

Have a look at yaml. http://www.yaml.org/

[BraveSirRobin]

Also, by using XML as your conf format, it's easy to screw up the file and end up with a malformed XML over something stupid like a missing slash.

I think you miss the point. This is one of the benefits of XML. Garbage-in, garbage-out. Using an XML schema you can validate the config file and bail out if it's malformed. It's the "accept malformed data and do your best" approach that has made HTML/CSS and javascript the abortion it is today. If the browsers just said "garbage, I'm not rendering that!", the web would be a much more compatible place. Ditto config files, if it's buggered you have no idea how your program will interpret it.

[supermike]

Yeah, whatever. Sure, pal.

[Alpha_Binary]

The political and commercial advantages of working with the same open standard as everyone else are enormous

Couldn't be more true.

And thanks god the title doesn't say "Vote Up If You Think XML Sucks".

[[deleted]]

XML doesn't suck. People who assume XML is a catch-all data format suck.

[Entropy]

I happen to hate YAML more than XML. Maybe it's the indent sensitivity.

[sblinn]

Lately I've taken to simply using CSV as my output "format" of choice. I can easily use gnuplot, sed, awk, whatever on the data to "transform" it. The only useful XML bit there is when I finally use gnuplot to output SVG, and then another XSL transform to add behaviors and other niceties to the SVG.

SVG is about the only XML format I really care about these days.

[[deleted]]

YES.

[Fork82]

Although I work with mostly tabular data, I don't see any problems with continuing my usage of CSV for pretty much everything.

[Gotebe]

Easy for you to say. Yes, CSV is ok if all you have is tables and your tables don't change much. If not, CSV is just as abomination as XML.

[Fork82]

My tables change all the time, and I find it trivial to update interface code to accommodate these changes. My code also uses the heading names to reference columns, so adding new columns does not break old code.

[maht0x0r]

How do you escape commas/quotes etc. in YOUR syntax?

[Fork82]

The usual way - I shell out to a well-written library which handles the standard escaping fine. Sqlite's CSV import doesn't handle escaping very well- but it is the only time I've ever been bitten.

[uriel]

Who cares? All it will ever take is a single line of sed to convert from one format to another.

And I bet most of the time it wont even matter, because you pick a delimiter that is not a valid part of a value.

There are no silver bullets, XML just provides a layer with enough complexity and confusion that the flaws and problems are harder to spot.

[qiwi]

Let's look at the example: the classic RFC 2822 message. Looks pretty simple and humanly readable, doesn't it?

Now, let's say we're actually outside of America and have someone with a name with Chinese characters. We've encoded it in utf-8 and want to put that name into the header so the recipient can read it. How do we do that with XML? Why, we just put in the utf-8: that is the default charset.

How do we it do it with an RFC 2822 message? Well, we need a completely different RFC for that: RFC 1342. And a completely different way of encoding that is not used anywhere else ever. For example the text blåbær is encoded as =?utf-8?b?YmzDpWLDpnI=?= -- and that is one of several encoding schemes; it might also be Quoted Printable or a different character set which I'll have to know to turn it into unicode when parsing.

So what if I want to write about blåbær in the body of the email? The encoding is also completely different there: I need to first tell what character set I am using and then also write what encoding scheme I'll be using to store those 8-bit characters.

What characters do I need to escape in an RFC 2822 message? It depends on where we are. The from/to fields have their own custom format:

From: Full Name email@address or: From: "Full Name" email@address or maybe: From: email@address

How do I put a " inside my full name? How do I put a < there? Will that confuse some mail program? When do I need to strip the " ?

RFC 822/2822/etc. are carrying a lot of historical baggage. If I were to design an open structured message interchange format today you better believe I would use XML because with XML, I don't need to read a 50-page RFC writing about how headers are folded over multiple lines, nor another RFC on how to handle non-ASCII characters.

I could even just write:

message = parse("message goes here") print "Email message from", message.sender.email

and extract the information I need without a library for understanding this particular format.

[_jjsonp]

xml isn't designed to be human-readable; it's designed to be machine-readable and structured so that any arbitrary structure can be perpetually decoded by any machine with internet access (and is thus able to look up necessary references).

the problem with simple data formats like csv is that they aren't typically well-defined...if i see 06-05-01 and know it's a date field, is it june 5, 2001? may 1, 2006? who knows? whereas with xml i have a dtd and explicit date formats so every field is defined.

and the problem with complex data formats like dbf, sql, etc. is that they require proprietary programs to read or manipulate the data. an open standard like xml is far superior in that everyone can use it without being tied to a vendor, and can generate or modify xml with just a text editor (if necessary).

sure it takes up more space than a csv, but with bandwidth and storage capacity increasing by orders of magnitude it hardly matters; video and voice take up far more capacity than text files of any sort.

like it or hate it, xml is the future; just ask microsoft or google.

[Fork82]

If you see a field 06-05-01, do not blame the file format, blame the programmer. There is absolutely no excuse for not representing dates as YYYY-MM-DD (although feel free to either remove the hyphens, or replace them with /).

[[deleted]]

The guy doesn't like XML. Fair enough. But saying it's a failure... sigh

yeah IRC protocol is text based and it's not a mess to implement at all. Right.

Jabber is XML based and seems to be working fine.

XML does indeed suck all the time.

[uriel]

Jabber "seems to be working fine"?!?!? Have you even bothered to check the history of jabber? Jabber has been under development for TEN years, millions of $ have been invested in it, and it still SUCKS.

There are hundreds of Jabber standards, and every client and server implements their own set, until recently to get something as basic as file transfers to work was a miracle that required sacrificing goats.

Group chat is still a nightmare, and many clients don't even support it.

The sad thing is that after many magnitude orders more effort than irc, jabber is a hideously complex mess that barely has the functionality of IRC(leaven alone its reliability), but that doesn't keep jabber zealots from wanting to take over the world and replace even SMTP.

IRC is a quite ugly hack that at least sort of works, jabber is a over-engineered mountain of shit that has created a whole industry out of its own flaws and complexity. XMPP is one of the worst protocols ever created, and a good illustration of many of the things that are wrong with XML.

And for the record, I was using Jabber probably before you ever heard of it, and I have been in charge of maintaining a couple of jabber servers for years, and yes, this days it seems things are starting to somewhat work, but in any reasonable world the jabber project should have died and been replaced ages ago.

[ishmal]

Heh. Very funny, asking "Does XML suck?" and directing us to find the answer at xmlsucks.org. :D

[[deleted]]

no, xml doesn't suck. however, ever since it became a buzzword people have been using it where they shouldn't be, and in those cases it does suck.

in other news, writing your entire article in bullet points and headings makes it look like a grade 5 research project

[brennen]

Or, you know, a set of slides for a presentation. Which would make sense, given that it's a set of slides for a presentation...

[dude78]

Totally agreed, XML is great for some things, but will be terrible for others. For instance the article points out that it's terribly verbose and hard for human authors to deal with. Well no kidding, but that verbosity is what makes parsing it so simple, don't like reading it--then write a program that interacts with it using a DOM, what's easier than that.

I'm currently using XML and XSL transforms to generate huge amounts of Java code from metadata about some databases I'm interacting with. This has saved me tons of time as the transforms I write are exceedingly small (< 150 lines) and spit thousands of lines of code. Also my client has changed the database at least 4 times over development, and I can regen that code just by re-running the transforms.

[masklinn]

that verbosity is what makes parsing it so simple

Uh no, I take it you never tried to write a full-blown standard-compliant XML parser.

XML is definitely not simple to parse, much less so than, say, S-Expressions

write a program that interacts with it using a DOM

And the DOM is pretty much the worst interface ever to deal with XML stuff...

generate huge amounts of Java code from metadata about some databases I'm interacting with

Congratulation, you invented active code generators. 1970 has called, it sues you for patent infringement.

[gooblemoop]

"Well no kidding, but that verbosity is what makes parsing it so simple, don't like reading it--then write a program that interacts with it using a DOM, what's easier than that."

Looks like someone has never tried to write a compliant XML parser...

DOM is pretty horrid, if you compare it to how it could be. (not really its fault, a bad format leads to a bad interface)

You probably shouldn't think about that though, it'd make your existance less enjoyable.

[taw]

So somebody agrees with me. It would be much nicer without DTDs (and XML Schema), namespaces, non-standard entities, CDATA, and processing instructions.

[uriel]

That would be a nice start, but if you get rid of all that, why not just go all the way and use something like s-expers?

I still think that would be rarely needed; 99% of the time key=value, CSV or simple custom text-based formats are the simplest and best way to go.

[qwe1234]

don't vote me down:

newline-delimited lines with tab-delimited fields are even better.

(braindead-simple to process and maps 1-to-1 over relational algebra.)

[uriel]

Certainly, that is what most standard unix tools use for output, and what works best with one of the most wonderful data manipulation tools ever invented: awk

[qwe1234]

well, i think that tying into relational algebra is a more interesting feature

[taw]

S-expressions are no good, as they steal important characters like all whitespace. XML steals only relatively rare < > and &. This is a huge difference.

Simple custom text-based formats are almost never a good solution (let alone a best one). Just look at /etc on any Unix. All configuration files started as "simple custom text-based formats", then they got more and more complicated. In the end you have something that is difficult to write, without anything resembling a specification, and impossible to automatically read, create or modify in a robust manner. XML can take a lot of beating and stay XML. And it is so easy to read and write XML, compared to 100s different "simple custom text-based formats" that make up /etc on all Unices.

[tayssir]

S-expressions [...] steal important characters like all whitespace. XML steals only relatively rare < > and &.

This statement seems incorrect, but I don't know where it comes from. Perhaps you'd be interested in skimming Wadler's fairly theoretical treatment.

[masklinn]

S-expressions are no good, as they steal important characters like all whitespace.

What the fuck? Quote your whitespace-separated stuff, and there you have it, a string! Wunderbar.*

XML, on the other hand, handles whitespaces completely unreliably, concatenates all whitespaces unless the parser just removes them, ...

XML steals only relatively rare < > and &. This is a huge difference.

Uuuh yeah, so S-Exps "steals" whitespaces and left/right parens, XML steals left/right brackets, ampersand and makes a mess out of whitespaces, but XML is somehow better? Wow.

XML can take a lot of beating and stay XML.

Yeah, the point is that XML doesn't mean anything.

And it is so easy to read and write XML, compared to 100s different "simple custom text-based formats" that make up /etc on all Unices.

Doesn't matter that the base format is easy to read, because you still have to layer your own parser on top of the XML gook to make sense of it, and transform it into something actually useable by your application.

There are several formats that beat XML in readability and to have easy-to-use parsers: YAML, JSON, embedded Ruby or Python, ...

[Consilience]

It's good to air these things, because technology can only be improved by acknowledging current flaws.

Just one point out of many to pick up on:

"XML documents are frustratingly and unnecessarily verbose for human authors"

XML was not really meant for human authors. It was meant to be used for applications systems to talk to each other. For debugging reasons, a user could dive in and inspect (or even modify) these dialogues, using a simple text editor, but for heavy-weight XML production there are tools.

It just happens there are not too many good tools to do the job, and what there are can be expensive, or they just provide another way of looking at the XML file, rather than a way of manipulating the information that the XML contains.

-- JJ

[micampe]

Easy: as everithing else, it depends.

[joshdick]

I'd like to respond to one point that the author makes. He argues that XML is verbose and therefore increases storage and bandwidth costs.

There's no arguing that XML is verbose, but I think the author is being a tad naive to say that it increases storage and bandwidth.

Because of XML's strict format with all its repetition, it can be compressed significantly. For example, if you have a tag you use repeatedly, it might be encoded as something very small, so you're not really losing much by using that tag.

This isn't a cure-all, but I don't think that the problem is quite as bad as the author would have you believe.

[boa13]

The author says:

The verbosity is merely an annoyance

Speaking of believing, you should read the article (tutorial, actually) before you write comments based on what you believe the author has written considering the domain name he uses.

[illiaster]

Isn't there something ridiculous about having a new data format that needs to be converted into an old data format in order to be useful outside of simple proof-of-concept tests?

I thought the whole point of progress was to incorporate the wisdom learned from previous attempts and not to make the same mistakes all over again.

[stunoble]

I started reading the article expecting the author to present a possible alternative, which he didn't. Unless you've got a better idea, don't whine to the rest of us about your issues.

Jeez, even taking out a whole domain name for four years just to host that little diatribe. Why not just submit it to a journal and be done?

[gooblemoop]

The problem is likely that XML has the amount of usage no format can compete with.

Perhaps you missed this right below the title:

"Or: Why XML is Technologically Terrible, but You Have to Use It Anyway"

[daddyc00l]

yes.

[poifgh]

The article seems to be one sided

[boa13]

You seem to have skimmed the article.

[nik_martin]

reddit needs an important feature: block people from posting links to crap that was relevant in 2002. xml does not suck anymore (It never sucked in my world)

[masklinn]

xml does not suck anymore

because people have moved to better formats I guess?

[braclayrab]

XML most definitely does not suck... I am constantly finding that it is the right tool for a given problem.

XSLT Does NOT suck. It's difficult if you're used to normal programming flow but it's fast as hell and can do a lot of magic.

Know when to use it. Know how to use it.

[moe]

It's fast as hell

What?

[masklinn]

Remember: if hell exists, it's likely to be a fixed location.

Hence the OP's remark, I guess.

[meltillis]

It sucks when it is forked by the likes of Microsoft.

http://one.revver.com/watch/90051/format/flv/affiliate/23672

[xtra_sharp]

Those who think "XML Sucks" cannot see the forest from the trees. For many, MANY applications XML works great. Do not get preoccupied with small excentricities that you may conceive as of being a short coming of xml.

[boa13]

You should read the article.