Firstly, I, like many of you, am glad to see that Dare Obasanjo’s indefinite hiatus from the blogosphere was short lived.

Secondly, while I most certainly agree with the premise of his recent “In Defense of XML” post — which was written in response to Jeff Atwood’s most recent attempt to get everyone in the XML communities of the world to hate him ;-) — the fact of the matter is:

Jeff Atwood is right!

Now before any of the members of the XML communities (of which I am a proud member of several!) pull out their pitchforks, and before any of the XML haters of the world declare some sort of moral victory, let me be perfectly clear:

So is Dare!

“WTF?” you say? Well, let’s first take a look at a portion of Dare’s argument:

My problem with Jeff’s articles is that they take a very narrow view of how to evaluate a technology. No one should argue that XML is the simplest or most efficient technology to satisfy the uses it has been put to today. It isn’t. The value of XML isn’t in its simplicity or its efficiency. It is in the fact that there is a massive ecosystem of knowledge and tools around working with XML.

Absolutely spot on! Then again, from Jeff Atwood’s recent “Revisiting the XML Angle Bracket Tax”:

I don’t necessarily think XML sucks, but the mindless, blanket application of XML as a dessert topping and a floor wax certainly does. Like all tools, it’s a question of how you use it. Please think twice before subjecting yourself, your fellow programmers, and your users to the XML angle bracket tax.

Absolutely spot on! XML isn’t the right fit for everyone and everything. In particular, when the most common use-case for a given configuration file is one that includes a *developer* directly editing this file for an application that runs on a platform that doesn’t natively speak XML, then chances are pretty good XML is the wrong choice.

But before I dig down further into my argument, let me first provide follow-up to a comment left by “markus” in response to Dare’s post referenced and linked to above:

But there is the BIGGEST problem of XML, which it can never do away - It was never meant for humans.

HUH???!!! Is that really a common belief by many of you out there?

What’s funny is that for those of us in the various XML communities who have been around long enough to have listened to, argued for/against, and in other forms have battled our way into making XML the defacto serialization format for things related to documents, data, and interop between them both, the argument will often times center around the very fact that XML was designed around the notion of being *human readable*, not the other way around. There’s an entire legion of folks who have been making attempt at building a binary XML format (something I wholeheartedly support), and the biggest wall they tend to run up against is the argument that:

If it’s not text, it’s not human readable, and therefore it’s not XML.

Of course, this would be a fair argument if one of the following two points were true:

* A binary format means it’s locked down and can not be “reverse engineered” back into its text “equivalent.”

* Binary XML == proprietary format that requires a custom parser and processor.

The fact of the matter, however, is that neither of the above are true. The argument for or against angle brackets is a red herring: What XML provides — whether that be text XML or binary XML — is a standard in which the industry can build upon in such a way that allows us to communicate with one another even though we may not natively speak the same dialect.

That said, editing binary XML directly would be impossible for a human. But the reality is that “human readable text” is only an illusion. Our editors our purposely built to hide all of the noise that would otherwise look like gobbledygook to us humans. So its not that binary XML can’t be edited by a human. It’s just that we haven’t built a massive tooling infrastructure that easily allows us to open up a binary XML file and edit it directly like we have for text-based file formats.

Could we? Of course! And maybe we will. But if we do, the conversion won’t be lacking angle brackets unless, of course, these same tools have built in features that allow the ability to edit an XML file in a grid control, a tree control, or simply a text editor that uses a WYSIWIG formatter to hide the angle brackets *and other* characters that can be conveyed to us in more human meaningful ways (e.g. a visible hard break in the white space instead of \n\r or \n or 
 or etc.) and therefore are otherwise not required for us to understand.

Of course, we have those tools today. For example, Visual Studio, oXygen, XML Spy, Stylus Studio, and 100’s of others that facilitate the ability to hide the complexities of XML, allowing us to focus on getting our work done instead of being “jabbed in the eyes” — as Jeff puts it — by angle brackets.

But that’s only part of the story.

The real success story of XML is all of the non-developer tools out there that have adopted an XML format that ensures our document infrastructure is founded upon a non-proprietary format that can easily be opened, edited, saved, parsed, and rendered on any platform and with any tool that understands how to parse the XML serialization format, which, as it turns out, just so happens to be *ALL OF THEM*.

Do Mom, Grandma Joe, and Uncle Bill know or even care that the document editor they are using stores their documents in an XML format? Of course not!

But that doesn’t take away from the importance of XML. What they gain is document portability, and therefore the option of using any tool they might choose in the future to open, edit, and save this same document. What we gain (meaning we developers) is a basic foundation in which — no matter what platform and toolset we might prefer to use — can build upon and extend from using off the shelf parts while at the same time ensuring the end result of our creation will be fully interoperable with the end result of the creation of someone else.

With all of this said, however, I do have empathy towards those folks who get XML crammed down their throats in places where XML isn’t necessarily the best fit. While one could argue that using XML as the serialization format for a config file — for example, the *.config files used in the .NET framework — allows the ability quickly and easily gain access to its properties and values without having to think about or even look at the file itself, there are certainly other options. And there’s certainly nothing wrong with using another format — like YAML, for example — that’s a bit more eyeball friendly.

There is a trade off, of course. With XML you don’t have to worry about things like indenting given the fact that XML uses an open/close bracket format to encapsulate its data structure and hierarchy. So if someone inadvertently adds a space or a tab where they shouldn’t have, the original intent of the configuration file is unaffected.

On the other hand, it’s slightly more difficult for a human to interpret and/or edit an XML file by hand than it is to interpret and/or edit a YAML file. And this is important for applications that require a lot of direct developer interaction with its configuration file, especially when dealing with frameworks that don’t have XML support built into their core (e.g. Ruby, which has instead adopted YAML as its core configuration format of choice) which brings us back to my argument specified above:

Developers who don’t regularly work with XML really despise the fact that they are often times faced with opening, reading, and editing an XML configuration file by hand.

Fair enough. It’s easy to understand why, *especially* when you consider that most of these developers are writing server-side web applications that — as a direct side-effect — don’t ever leave the machine they were created on, and if they do, it’s usually related to checking the file in and out of a VCS of one type or another or in other ways distributed in a “safe” container (e.g. Ruby gems, Python eggs, etc.) that ensures the implied structure — in this case YAML — remains intact. So the benefits of “interop” are irrelevant. What’s there to interop with? It’s a configuration file, and that same configuration file — unlike, for example, an ODF, OOXML, XHTML, and other document types that gain the derived benefits of using XML as their base format — will never have to be read and/or interpreted and/or edited and saved by an application it was never intended to provide configuration settings for.

But does that mean XML truly sucks, or does it simply mean that when writing applications that:

1) Are built on platforms that don’t natively speak XML.
2) Primarily reside in a server-side environment.
3) Utilize configuration files that contain application specific settings as opposed to user specific settings and therefore have no need to be deemed “portable”.
4) Have a high probability of being hacked on, re-configured, and in other forms customized by developers for their specific needs.

… that we, as developers, need to be a bit more mindful to the needs and desires of our “target audience” and, for the reasons specified above, utilize configuration file formats that are free from the “clutter” that is often times associated with the combination of angle brackets, namespaces, and namespace extensions?

Yeah, I think we probably should.

On the other hand, I believe that it’s important to point out that we are moving further and further into a world pwned by XML — Document formats, Web Services, declarative UI languages, etc. — so while it might make better sense to *standardize* on YAML for server-side application configuration, that doesn’t mean you, as a developer, shouldn’t learn all you possibly can about XML. It simply means that you don’t have to directly muck with it inside of your text editor of choice, which, if not mistaken, is the biggest beef the XML haters of the world have with the XML format:

They don’t mind working with it in code, they just don’t want it gouging out their eyeballs and/or would prefer to keep the Carpal Tunnel Syndrome at bay for an additional 10 years or so.

Seems fair enough to me. What about you?