I’m not the only one who thinks XML could be made simpler: XML 2.0 proposal by Elliotte Rusty Harold. At least some of these ideas are good: predefining all the HTML 4.0 entities would be great; getting rid of internal DTD subsets and CDATA sections and leaving validation out of the core spec are winners; building in proper namespace support should have happened already. I’m less sure about others: XSD simple types are way too complicated, but I never felt the need for XML types to match the type system of whatever programming language I happened to be using.
As long as I’m talking about XML, Adam suggested in the comments to my previous post that vendors add complexity to solve the problems of their customers. I responded with another comment, but I’d like to expand on that. I do think that the problems of big enterprise customers are less complicated than most people think. The real problem is that enterprise vendors usually sell to people (executives) who don’t actually use their products, and therefore often base their decisions on check lists of features, so that the vendor claiming the most features wins. YAGNI (“you ain’t gonna need it”) is a losing proposition in this environment, so architects design for every possible contingency, which means things get more and more complicated.
I agree, and also wanted to add something. I believe the executives in most organizations have a feeling that there is too much software complexity, and it’s getting in the way of getting things done. In some cases, they’re correct.
Then, someone comes along who says, “our product does everything, all integrated together”. This sounds, from the executive’s perspective, like a way of reducing complexity, which is their core concern. So, they buy it.
The bait-and-switch is that it’s not reduced the complexity at all. Instead of a car with a very complicated engine you have to tinker with a lot to get the parts to work together, you now have a car with a very complicated engine and the hood is bolted shut so that you can’t work on it at all. The problems of integration are still there, you just can’t get to them as easily.
The one benefit of this approach is that, when the right answer is to leave something alone and just deal with it (sometimes true), IT cannot win that argument with a homegrown product but can easily win it with a purchased product, since the bad guy is then someone else. This is not to say it’s a net win to use a monster package from an enterprise vendor, though.
I see a lot of things about our environment that make it different than many open source products assume — that’s why we have applications like PyPE. I’m of two minds about that, but it may not be complexity per se.
As far as XML’s complexity: I guess it would depend which features you are pointing at. We’re using XMLDSIG for XML signature validation — is that “complexity”?
I think executives often buy the wrong products, probably for a variety of reasons, but that’s kind of a separate issue.