Object vs. XML

I was watching a group of folks present a new XML standard the other day and I realized something for the first time: to XML folk, OO languages are just script-like “glue” for connecting XML processing steps, the “Unix pipe” of the new millennium, if you will. Integration with OO languages is necessary to enable XML dominance, but that’s an accident of history. In the view of the XML zealot, OO will eventually fall away and only pure, clean XML will be left in its place.

As an OO guy, I find this view disturbing. As a general technology wonk who sees the value of XML, I find this view unrealistic. Just so you XML folks know, OO guys look at XML as a data transfer syntax and that’s all. OO guys are happy that XML is there, but they prefer to stay away from it in favor of their nice, familiar OO environment.

The problem, of course, is that many XML guys are so steeped in the new world that they forget where they came from. To paraphrase the Matrix, XML guys don’t even see the angle brackets anymore — they just see blonde, brunette, redhead. OO guys, of course, *only* see the angle brackets and prefer their artificial world-like simulation.

The result of this massive gap between XML and OO folks is that the great thing that the XML guys are building, i.e. a general-purpose hierarchical data manipulation, transformation and interoperation infrastructure, something that OO guys desperately need, is being lost because the two groups don’t know how to communicate with each other.

So, to enable XML to dominate, XML folks have to be sneaky. Just like OO finally took off in C++ when it provided a super-set of the procedural programming in C, XML has to provide a super-set of OO programming, down to the easy syntax and the compile-time type checking. Only when you give the OO guys exactly what they already have can they begin to see what new things you’ve given them.