This morning I find myself pondering one of the more subtle coincidences of my daily life: this month my company, Altova, launched not only a formal standards-based XML certification exam, but also new training classes for our first systems integration-oriented tool, MAPFORCE. Beyond the blatant plug for my team's work, why is the proximity of these two very different educational efforts interesting? Well, on one hand the new XMLSPY Certification is mainly about the nitty-gritty details of the core XML standards and less about Altova's tools or the sexier new XML dialects like SOAP. On the other hand, our customers are clearly becoming interested, like much of the rest of the XML world, in looking at systems integration issues that treat XML processing like grimy plumbing between shiny bits of binary code.

OK, that may be overselling the point somewhat. However, the misguided attitude that XML is merely a simple, even trivial, markup language is not uncommon. As one example, a recent interview with Sun Microsystem's Victoria Livschitz characterized the current industry enthusiasm for XML as a "setback" that "will be haunting our industry for decades" (The Next Move in Programming: A Conversation with Sun's Victoria Livschitz: http://java.sun.com/developer/technicalArticles/Interviews/livschitz_qa.html). Moreover, even in these very pages, in past years, observers have delivered the verdict that XML is easy, but code is the stuff that careers are made of (Volume 2, issue 8; page 12).

I can say, "Sure, XML is just a supporting technology in many cases," though many XML people would probably resist the idea fiercely. However, rather than fighting back with an argument on the sophistication of data modeling in XML Schema or a diatribe about how XSLT is a full-featured functional programming language, let's take that statement at face value for argument's sake. How much time should any of us really spend thinking about a "supporting technology"? How do you make that call?

As a "supporting technology," I think it is fair to say that XML does some fairly heavy lifting. In most cases where I've seen a development team working primarily with Java or C++ or another language but also significantly with XML, the XML is a load-bearing pillar that cannot be easily removed. And in fact, industry opinion apparently concurs with my experience. There is no other explanation for the prevalence of XML languages, interfaces, tools, and technologies.

Over the years I have seen a number of so-called supporting technologies come and go. I have seen many successful projects and others that were not so successful. One commonality I have noticed in successes and failures alike is that the teams that take supporting technologies lightly tend to find that their load-bearing walls are built on sand, not cement. The successful teams, by contrast, may not have been experts at the outset, but they tended to take a considered and appropriate approach to each tool and each technology they used.

One of my main goals in leading projects and recommending technical and architectural strategies to organizations has always been that we take our technologies seriously. To put a finer point on it, my goal is to use each technology only on its own terms. Clearly, creativity is a driver of the high-tech economy, but, just as clearly, every time I see C++ paradigms used in C code, and ASP written in Perl style, and Eiffel principles seeping into Java, I see the walls buckling. As developers, our approach should be to understand and respect the intent of the people who created the foundations of our technical platforms.

Once you are past that basic point you get to where it is possible to be creative or to allow yourself to be distracted or to simply get on with your work. Only when you have a solid foundation within your starting frame of reference can you think seriously about integration with the bigger picture. This is where I come back around to where I started. To me, the interesting thing about a tool like MAPFORCE is that it looks Java, C#, and C++ squarely in the face and acknowledges that they are the leaders, and XML is in the "supporting role" - in the sense that it becomes the foundation. As a person working at an intensely XML-focused company I am comfortable with that idea mainly because I am confident Altova does not underestimate the value and richness of XML. With that confidence I can look forward.

Not underestimating is important in any walk of life and confidence is typically a good thing. Both are generally the result of serious study and thought. In my humble opinion, nothing can go unexamined and still be a source of confidence. So, to my way of thinking, a practical and completely XML-centered XML certification test is basic infrastructure for enterprise developers that want to leverage all that XML has to offer. Only after that foundation is taken care of does life get exciting. Anything else is complacency. As John Adams famously put it, "I must study politics and war that my sons may have liberty to study mathematics and philosophy."