Do XML Editors Matter?

by Bill Trippe

So far, there hasn't been a great deal of XML typing going on out there. Part of it is the manner in which XML is being used. It is typically used in interserver communication and other situations where XML is created on the fly from other sources, such as database tables being mapped to XML structures. As a result, updates to the data sources may still occur through traditional forms-based interfaces. The data may end up as XML, but the user probably hasn't had to confront XML coding.

But as more CM technology is deployed, the need for XML-encoded content will increase. CM systems typically rely on forms-based or "template" interfaces for content entry, but these interfaces have their limitations. Templates begin to break down as soon as content becomes lengthier and more narrative, or as soon as more challenging materials such as tables and equations are included. Typically, the trusted tools that word processing users rely on are gone, too: WYSIWYG-style editing, spell-checking and features like edit trace for collaborative authoring.

Yet the template approach has become de rigueur in CM because they are an easily programmed interface to the underlying CM system. Word processors, while a better interface for editing, leave an author at arm's length from the underlying database, creating material that can only be introduced to the database after complex processing and human intervention.

XML is ideal for this kind of document creation, where the author may need to create both fielded data suitable for a database and more narrative text found in business documents, technical manuals and catalog data. You can view XML as the bridge between the two worlds of structured (relational) and unstructured (document) data.

And herein lies the rub. On one hand, you have a growing need for content to be tagged at its source and maintained in a structured form. On the other hand, users are resistant to more complex tools and processes. XML editors seem to be the solution, yet the market has been slow to develop, and resistance has been strong.

"This is an awkward time in the market," admits P.G. Bartlett, vice president of marketing at Arbortext, a provider of XML authoring tools based in Ann Arbor, MI. "It is not yet common wisdom that tools designed for single-channel publishing are not yet suitable for a multichannel world."

Content has become a multichannel world, with the first two channels, print and Web, well established and others on the horizon. Moving forward, all businesses will operate in at least these two channels, although not every business will have content that requires extensive XML encoding. More complex and lengthy content types, such as catalog data and technical documentation, will move toward storing data in XML.

It's time for organizations to analyze what content they need managed and in what forms. XML will not be the format for all data in organizations, but it will be for at least some types of data; and that data will need human upkeep and intervention. Where content is best expressed as XML, organizations must deploy the best, most productive systems for authoring and management. Such systems could be XML-savvy content-entry templates, or they could be full-blown XML editing tools tightly integrated with back-end databases. Analysis should guide the decision-making, not some vain hope that the wrong tool will somehow do a job it was never designed to accomplish.

Bill Trippe (btrippe@nmpub.com) is president of New Millennium Publishing (www.nmpub.com), Boston.