In a thought provoking post I See Markup, Part 5 - Not Chasing Standards Ben Bryant complains about the extra work that is needed for developers to support various XML standards.

On the other hand, he should probably be thankful because it's precisely because of this that he has a sustainable business :) Ben is the author of CMarkup, a lightweight C++ parser for XML that satisfies a niche. Those that want a fast solution that is trivial to integrate into their C++ code base probably should be happy with his product. But things are not as simple as they look - for example, Ben claims that:

But I never saw the business case for XSLT 1.0 let alone 2.0. To me, solutions formed around XML transformation by style sheet and even validation by DTD/Schema are "artificial". I call them artificial, because they create work rather than solving a problem. They are unnecessary detours because programmers would otherwise transform XML for viewing in more direct ways and validate their data in more natural and reliable ways, using tools they are already familiar with.

The truth is as usual in the eye of the beholder. For some of Ben's users, his product is God-given; they don't have to learn anything new. But this is precisely the reason why it might be dangerous to look into the world of XML through the CMarkup colored glasses - you might miss that there's a lot more out there than you think.

Here's an example - one of the tasks I had to implement once was to transform an XML representation of a formula like structure into text. The developer who worked on the task before me already put in place C++ SAX based parsing solution, but at the time he did it the XML was quite simple and this worked fine. In the meantime the requirements changed and the new structure was quite a bit more complicated - note that there wasn't much of data, but its structure was involved. After struggling with C++ for a while, I noticed that the problem can be almost trivially solved with XSLT, so I did. I am sure that CMarkup would make the solution simpler than C++ SAX solution I had to start with, but just because XSLT is not well suited for certain transformation cases does not mean it is useless for other.

Yet another example is reading XML documents without a schema from C++. I am sure that you can get even malformed XML with CMarkup very fast but what would you do with it in case many elements contained optional attributes and sub-elements with default values? Litter the code with zillion ifs to check if something is there or not and then populate defaults? How would you check for deeper structural dependencies between elements and attributes? Ah, but you wouldn't - your XML documents would be trivially simple (in structure!) anyway.

CMarkup is great tool for a specific purpose, but might be horribly inadequate for another. While it helps those that have simple structured XML documents to deal with and just want to get the job done, it also supports the lazy among us developers who cannot be bothered with specs. This can sometimes result in developer thinking that “this whole XML thing” is really simple and start producing ill-formed and invalid XML. Here's an example of that - name one thing that is the hardest part of building an RSS/Atom reader? It's not following the standards of the RSS/Atom markup, it's struggling with all kinds of ill-formed markup that content producers spew out. If we'd all pay just a bit more attention to “boring” specs, the interoperability (that everyone seems to agree is the good thing) would be so much easier.

In conclusion, I don't think that the fact that CMarkup exists (and is quite useful in a special niche) invalidates specs for any XML technology. Right tool for the right job - sometimes this will mean (a bit) more work for developer.