a thousand furnished rooms

There are several broad categories of choices for XML editing:

1 - Commericial XML editors intended for use by editorial and production users. The major players in this category are XMetaL and Epic. These are also the only editors that have an integration with Documentum that allows XML documents to be appropriately processed (chunked) on check in and check out. (While Documentum allows the use of Word as an editor, special customizations would be needed to integrate Word as an XML editor.)

2 - Commercial or shareware/freeware XML editors mostly intended for use by software developers but also an option for editorial teams who can't afford more or who have very simple content. Products in this space range from XML Spy (expensive developer's tool) to a wide variety of free/inexpensive tools that work like glorified text editors (I don't mean to disparage these - their XML capabilities can be really great - but the view to the user is "geeky," not the word processing view available in XMetaL or Epic).

3 - Non-XML editors in combination with custom scripting/programs to convert content to and from XML. Even though it does have some new XML capabilities, MS Word still falls into this category. Whether you use its XML capabilities or not, you must still write scripts to transform your content to the needed DTD after you close a document in Word, and to transform the content into a form that Word can use when you open a document. This can work extremely well for content like news that does not have a high level of nesting in its DTD, but is expensive to maintain for complex content (it's difficult to script for all the myriad of things people can do to content in Word). For complex content, it ultimately requires more custom programming and maintenance to make Word into an XML editor than it does to add some nice word processing features to a native XML editor. Using Word or another word processor also has other negative side effects. In particular, it results in your editing and production staff not really understanding XML or your DTD.

It is true that there is a learning curve and cultural change required for staff to become familiar with XML and with using an XML editor versus a word processor. This change always involves some discomfort but also comes along with lessons that are highly valuable to a business. The two primary lessons are (1) a clearer understanding of the purpose of each person's role (e.g., my job is to add value to content, not to worry about how it *looks* in various outputs) and their ability to focus more clearly on their individual goals and (2) a broader understanding of the big picture - how what they do in content affects all outputs (all re-uses and all media). Yes, the transition to XML requires cultural change, but it is beneficial change. Yes, an XML editor constrains users, but it constrains them with a purpose. In the end the benefits of an XML editor outweigh the negatives significantly.

All that said, it is still possible for the *way* in which an XML editor is implemented to cause problems or be unnecessarily complicated for users, but that is a topic for another time.