During the past few months I've seen several discussions on the validity of the term XML developer. Does this breed of developer exist in today's computing industry? Has XML matured to a stage that it warrants job descriptions for developers who specialize in XML programming? Is there an independent category of programming that relates primarily to XML?

For example, recent articles in XML-Journal (Vol. 3, issue 3) have sparked a discussion in the community that orbits around the needs of the XML developer - a new breed of developer whose scope of work encompasses a multitude of different XML-related technologies to a point where the actual programming language these folks work in is no longer relevant. This is much the same process that has occurred in other areas, and gave birth to the database developer some 34 years ago with the standardization of SQL. I'd like to address this issue here, and demonstrate that XML and the XML developer have definitely come of age.

In light of this development, the behavior of such a developer certainly bears investigation, particularly with respect to development environments. This will allow us to shed some light on the recent debate about whether there is a natural synergy between classic IDEs (such as Borland's JBuilder or Microsoft's Visual Studio) and XML IDEs, or whether these IDEs will compete in the same marketplace.

The XML developer typically works with any number of XML-related documents, such as XML files, DTDs, XML Schemas, XSLT stylesheets, XPath expressions, WSDL and WML files, SVG (Scalable Vector Graphics) files, XHTML documents. The list grows almost monthly as various standards organizations produce a never-ending stream of new proposals and recommendations. The work done with these documents depends largely on the specific application, but typically includes such tasks as creating XML use-case scenarios, developing DTDs or schemas, creating instance documents (either programmatically or by hand), validating instance documents against the defining schema or DTD, designing XSLT stylesheets, developing Web services, testing Web services for interoperability, and debugging XPath expressions. The list also grows as we discover more scenarios in which XML can be applied to solve issues in new domains.

It's certainly true that most classic IDEs have recently added XML-related features to their repertoire of classic edit-compile-link-debug functions, but their focus undeniably rests on the programmer, who is tasked with creating software that produces or consumes XML data - a narrow view that doesn't do justice to the scope of tasks previously discussed with respect to the needs of the XML developer.

Take the latest Visual Studio .NET release, for example: this adds a simple XML Schema editor, some XML support in the generic text-editor, and schema-only validation to the Visual Studio IDE, which is a rather typical modern programming-language IDE (supporting C++, C#, Java, Visual Basic, and other languages through third-party plug-ins). While these new XML capabilities of Visual Studio will certainly help those developers who only casually need to touch up a schema or briefly look at some XML data once in a while, there are also lots of people out there - true XML developers - who work with XML, Web services, XSLT stylesheets, and XML Schemas on a daily basis. These people need many more XML capabilities than the programming-language IDEs such as Visual Studio can provide.

This is where the XML IDEs come into play, in that they are totally focused on providing XML-centric features to fill the needs that a classic IDE does not address, such as:

• A graphical XPath Query analyzer to visualize the resulting node-set of an XPath expression
• A schema generator that can extract and create an XML Schema from a set of different use-case XML instance documents or derive it from an existing SQL database schema
• A SOAP debugger that can intercept Web services transactions and set conditional breakpoints on the value of any payload element selected by an XPath
• And thousands of other little details that make life with XML easier

This also illustrates an important aspect of what makes a true XML developer - the term isn't necessarily restricted to people who write programs that emit and consume XML data. On the contrary, people who analyze requirements specifications and develop DTDs or XML Schemas, who develop stylesheets for transformation to diverse presentation form or interfaces for Web services - they all should be considered XML developers.

But the definition should be broader. Instead of restricting it to the classic developer (i.e., programmer) who just happens to work with XML, the XML developer is a person who develops XML-related materials - be it DTDs, schemas, stylesheets, or programs. This is analogous in many respects to the concept of a database developer or a Web developer - both terms describe much more than just the creation of programming language statements that deal with databases or Web pages!

As a result, we can now view XML-centric IDEs and classic programming-language IDEs from a new perspective: they aren't competing with each other, but instead are symbiotic in the sense that one provides what the other doesn't. These different paradigms are really complementary, and tools in those markets will continue to integrate well to provide developers in need of both sets of tools - programmers who are also XML developers - with a synergy of capabilities that make them truly productive.

To validate this perspective, let's take a look at an established market (>30 years) with a different powerful paradigm - SQL - and we'll see the same picture. Many programming-language IDEs provide a small set of SQL features to address the needs of the average developer. At the same time, there are several tools on the market for true SQL developers (or, more generically speaking, database developers) - for people who work with SQL daily and need more SQL capabilities than the run-of-the-mill IDEs can provide. Some of these SQL developer tools are so feature-rich that you could call them SQL IDEs, because they address those needs perfectly.

To use a more recent analogy, consider the case of Web development tools: while you can certainly create Web sites using classic IDEs - and some of them do indeed provide some HTML features - most professional Web developers still favor a Web development tool, such as Macromedia Homesite, for their Web-related work and typically use it in conjunction with a classic IDE to get the best of both worlds.

It's therefore valid to assume that things are going to play out similarly in the XML market space - history is prone to repeat itself....

In addition, of course, there is the issue of XML editing beyond the need of the developer, which is again something that's typically addressed by other components in the product line of XML vendors: graphically designing XSLT stylesheets (which is more a task for Web designers than for developers) and editing XML content to be stored in content management systems (which is important for all areas of enterprise knowledge-management). These things aren't going to be of any interest in programming-language IDEs at all, and consequently there's another field of possible synergies out there to empower XML developers with the tools to create and integrate such content-management solutions within the entire IT infrastructure of enterprise customers.

In the end I think we've established beyond doubt that there is indeed a new breed of XML developer out there. They come from a diverse variety of backgrounds that certainly includes - but is not restricted to - programmers, who will need both a traditional programming-language IDE and an XML IDE. To limit the scope of the term XML developer to programmers only would certainly be a huge mistake and wouldn't do justice to the entire idea of XML - to be extensible beyond our current imagination.