I think James Clark got this one right: "Any damn fool could produce a better data format than XML." The value of XML lies in that everyone agrees on it, and in what the tools do for you, not in its technical excellence or beauty.

Another common complaint is that XML is hard to read or time consuming to author.

I wonder if this criticism would go away if there were better default tools for dealing with XML. Currently, most people - whether they are beginners or advanced - use text editors to deal with XML.

One of the reasons this is difficult is that you typically need different things from your editor for different dialects, for example whitespace may be important in one but not another.

Anyway, I still typically use a text editor to write XML, although I may choose to view it in something else, so all this is pure speculation.

Thanks Norm for the excellent rebuttal.

The only thing I would add is that Atwood's comparison with RFC-822 was particularly unfortunate, obviously he has never seen any of the hilariously complex regexes needed to find dates or email addresses. XML is a clear win here IMHO.

Most complaints I am aware of are in the tools and in the impedance mismatches.

1. Try shoehorning even a moderately complex XML schema into a relational database or vice versa if one wasn't designed for the other.

2. Tools intended to ease the development like the use of annotations in SQL Server don't unless item one was considered. It's just ugly.

3. Simple ideas like VRML97 scene graphs created ugly XML schemas because of the object-has-an-object attributes-can't-have-elements mismatch.

In short, mapping into and out of the tree is doable but painful and the shortcomings are often attributed to XML instead of the application languages that were shoehorned into XML Schema or XML itself. But we've been shoehorning since the beginning of the HTML-endowed Internet. A lot is learned that way but some devolution occurs. No size fits all comfortably for some.

I would emphasize a couple more points:

-extensibility

-relative access

How often can you freely extend a data structure without generally breaking existing consumers of this data structure?

How often do you get a relative access to a particular element of information without the need to understand the entire data structure?

When you combine that with all the benefits you listed, I see a compelling reason to deal with minor syntax or tooling annoyances.

P.S.: it is really annoying to mark up a comment to make it look ok...

Hi Norm,

My comment is completely tangential/irrelvant to this particular post as a whole, but as far as the " On the other hand, it's pretty obvious that XML _is actually better_." hyperlink:

I personally think it might be really nice if that particular link didn't send me to a page that had a big blank space with a note saying "If you had Flash installed you'd see a nice graph here".

Hoping you might be able to do something to change that.

--Mike

The difference is large enough to piss me off.

Imagine you're using XML for a properties (key/value) file, say for configuration.

You wouldn't write unit tests for that? Interesting. Personally, I'd trust a XML tool-chain about as far as I can spit.

Rusty Harold Elliot, some time back, gave the example of borking apache's configuration file. Whitespace in the wrong place or something. That unfortunate design choice was a justification for using XML.

The correct answer, then, now, in the future, is to write your own grammar. For a typical configuration properties files, it'd be pretty straightforward.

To anyone who believes such an exercise is too hard: Yet you're willing to write an XSD, DTD, or RELAX-NG? Please. (Sidebar: My VRML97 grammar implementation was smaller, quicker, and more correct than any XML-based "solution".)

In review, for the back of the class, please pay attention:

If your answer is XML, you asked the wrong question.

Cheers, Jason Osgood / Seattle WA

Norm,

Thanks for the thoughts about the values of XML.

I work in the financial industry. I have seen XML used several times resulting in global applications that easily exchange data between multiple countries or multiple financial institutions. The few extra characters required by XML compared to a flat text file are nothing compared to the advantages of using XML. The advantages include not having to argue about which format to use, like in the old days before XML, and the availability of validation. The advantages of using XML include each party being able to use the tools they prefer to manipulate the data, not like in the old days when use of proprietary formats resulted in all parties being forced to use the only available tools for processing that format. Yet another advantage of XML is not having to worry about parsing files with extra blanks or using characters from languages that you never expected to see, like in the old days.

Rolling your own is for those with no imagination or foresight. Some people cannot imagine that data or information has any value other than in the particular context of a single task. XML is all about capturing data and information in ways that perserve value for unknown uses. Not only is XML extensible, but XSLT allows reformating from a particular vocabulary to another. That this is always perfect, but there are rules and tools and organizations to support it worldwide. IT should not be about making the programmer's task easier at any point (as many seem to think), but about giving the most utility to the data or information now and in the future.

Jason,

XML obviously doesn't work for you. However, consider the following - VRML does have an XML equivalent called X3D which is gaining adherents precisely because it can be validated without writing your own grammar, because it can be generated from external content in other contexts, and because it is possible, once loaded, to modify the X3D content in a consistent manner without requiring a specialized API.

Writing a grammar is not hard. Writing a grammar + parser + documentation + distributing it to everyone who uses it is much harder. I've worked with configuration and INI files on many different operating systems over a thirty year span.

I've discovered what happens if you edit many of these text files in a text editor without a way of validating - you can quite readily end up doing things as diverse as royally screwing up your operating system, make it impossible for your video driver to actually render content to the screen, cause mechanical malfunctions and so forth, often times by doing something as simple as forgetting a tab or using the wrong number of spaces.

I've also spent hundreds of hours over the years trying to figure out cryptic man files that existed as the only documentation for a given command trying to figure what exactly the grammar being used actually was.

You're free to use whatever format you so choose - but I'd rather take the slight verbosity of XML over a poorly written and deficient configuration grammar anytime.

I'm just wondering what the argument is in favour of XML vs YAML?

I switched to YAML a few years ago and it got of a ridiculous number of XML caused headaches.

1. Lisp is a better answer than XML. Lisp allows you to store data in exactly the same manner as XML. You still get the parsing for free, but you can also manipulate it to your heart's content.

2. Yes. Unequivocally.

3. Probably not :P

4. One syntax for data AND programming seems pretty easy to me.

Re. Lars Marius' quote from James Clarke "Any damn fool could produce a better data format than XML", I really ought to know better than to second-guess James's intention, but I read that as "If we'd wanted to invent a data format, we wouldn't have invented XML".

I read Jeff Atwood's article too, and it's just the same old, same old. I'm not a programmer, I'm a publisher, and for me XML is nothing short of revolutionary, because of what it has enabled: the separation of form from content; self-describing documents; human readability; easy extensibility.

Can someone please explain to computer programmers that XML was not created to make their lives easier, and that it is a text format, not a programming language (at least in its narrower sense). So to Jason and his pals, I say stop whining: it was tedious five years ago, when there was still a debate. "My VRML97 grammar implementation was smaller, quicker, and more correct than any XML-based "solution"". Well, I bow before your godlike genius, but don't ever ask me for a job: I like my staff to live within commuting distance of Planet Earth.

If you want to compare XML with something, a comparison with RTF might be instructive:

Try loading a single RTF file into the last 3 major releases of Microsoft Word (let alone WordPerfect) and see what you get.

Try writing an RTF document in NotePad.

Try re-purposing an RTF document

Try stripping the formatting from an RTF document.

Then there is the document quality angle. I've written and distributed dozens of Word templates over the years, some of which have done some quite fancy stuff. When I got the documents back, authors had typically ignored the toolbar button I had created for applying a Heading 1 style with a single click, and instead labouriously manually formatted and aligned a paragraph of "Normal" text, because they "didn't like the way the other heading looked". So I end up with a 50 page document, every paragraph of which is styled Normal, which I'm supposed to auto-convert to a DTP file.

XML prevents that sort of abuse, enforces regular document structure, and embeds meaningful metadata/semantics into documents in a largely unobtrusive way. In doing so, it moved the re-use and re-purposing of content from fantasy island to reality city. That's a galactically big achievement in my book.

xml is designed to be (unequivocally) machine readable, and it does a pretty good job at that. Maybe some of of it's critics are young or have short memories but I can certainly remember spending way too long going nearly crazy trying to decode idiosyncratic data files, and, also, trying to invent data formats that wouldn't do the same to others.

If xml isn't easy to follow, maybe we need some better viewers and editors, both generic and purpose-built. I don't know if there's a spec for this already, but you could potentially have a "xlv" viewer spec - like the xls content spec - that specifies good human views "hints" for an xml data scheme: styles, shapes, key elements, and so on. I can't see why anyone should really be editing xml tags - well, sometimes you've got to work at the low level - there's really got to be better ways to display and interact with data. But the xml can and should remain the definitive statement of the data.

If the tree data model doesn't really work with you data, you have to either get off xml and loose it's universality and robustness, or, transform the data into it's natural shape before you even look at it. If you're working in a dumb text editor you're up against it.

Why no mention of binary XML? Doesn't that get rid of the angle tax?