There was a period around 1999-2000 when anything XML was hyped beyond belief. An XML-centric GUI tool, no matter how narrow in focus, attracted interest and, often enough, VC funding. The net result was a myriad of XML tools - really XML gadgets - that tried to address a large number of overlapping small problems. As a rule, all the GUI tools vied for the .xml (or .dtd, .xsd, .xsl, etc.) file extensions and interoperated poorly with other software.

Let's take a quick inventory of XML tools on my work computer: six XML document editors, two schema editors, three XSLT stylesheet editors, three data-mapping tools. And these are just the GUI tools. I have dozens more parsers, transformation, query and search engines, repositories, etc. How many of these do I use regularly as stand-alone tools? None. And that's the message I get from many people I talk to.

I believe the reason for this is that the majority of XML tools vendors miss the single most important message about XML: it's a tool (no pun intended) for getting things done, not an end unto itself. Users don't want tools that are focused on XML. They want tools that are focused on solving their problems. XML can be part of the overall picture, but it can't be the major selling point.

Another way to look at this is to ask whether working directly with XML is of primary importance for someone's job. For example, working with text is of primary importance to business writers, and that's why they use a stand-alone tool such as Microsoft Word. Software developers spend most of their days working with Java/C++/VB/other source code in integrated development environments (IDEs). Web site designers use tools such as Dreamweaver and HomeSite many hours each day. Who has to work with XML several hours per day? The main group is people building highly structured documents such as catalogs and technical manuals. They use XML in a document-centric (as opposed to data-centric) manner and need highly customizable, WYSIWYG XML instance editors such as XMetal and Arbortext.

With the exception of the people authoring highly structured documents, the rest of the professional computer users spend most of their days working in tools whose primary focus is not XML.

For example, a Web site designer may need to build a simple XSL stylesheet to transform back-end data into XHTML. A Java developer may need to modify a build script, which is an XML document. In both cases, however, people don't want to leave their primary tool of choice to get the job done. This is why Web site design tools and IDEs have become friendlier toward XML document editing. Further, in cases where the document schema is fixed (the build script being a good example), people would rather use a GUI tool specifically designed for script editing as opposed to a generic XML editor.

This environment creates a quandary for XML GUI tools vendors. They can do one of two things. They can focus on integrating with users' primary tools or they can try to secure themselves a position as a primary tool. To do the former, companies need to focus on building embeddable technologies and developing the partnerships that will allow them to deliver these technologies on top of the market leaders in the business productivity, Web design, and application development space. To do the latter, vendors will have to identify market opportunities that will lock users into their tool for some reasonable portion of their work. For example, a tool can become very successful by owning some key piece of the overall solution workflow without the need for associated infrastructure (think Visio).

From a business perspective, the embeddable OEM model is likely to create small niche players. They'll come and go quickly as the specific problems users have to deal with change. Don't expect many IPOs in this space, but there will be some good opportunities for nimble entrepreneurs and investors. I'm still waiting for the Visio of XML tools to appear. Keep your fingers crossed.