We would like to make a point that, given the space limitations of this print article, we can cover only a small number of the key features that distinguish these tools. We plan to create an online report that will provide more details, including many screenshots of key features, a glossary of terms, links to documentation on all these XML Editors, and mention of dozens of other XML Editors that did not make the cut for EContent but might fit your niche.
For a sophisticated developer, any good text editor can be used to create XML documents, XML schemas, and XSLT style sheets. Among the most popular are HomeSite and UltraEdit (Windows), BBEdit (Mac), Emacs (Unix), and jEdit (cross-platform Java), our favorite tool. These typically have validation, tag-completion, elements in context, etc. And jEdit recognized the ditabase.dtd properly from its DOCTYPE declaration, where our reviewed XML Developer Editors surprisingly could not.
Here are the key features we focused on in our examination of these tools:
IDE. An XML Developer Editor that is the central part of an Integrated Development Environment is a must-have tool for any organization moving its content to XML. Since that now includes all content, at least one person in your organization needs an IDE. We judge the IDE tools by how many different aspects of XML they support. They should not only work with XML schemas and DTDs, they should provide full creation and debugging tools for these schemas. Perhaps even more important, they should let you design, debug, and deploy the many different style sheet transformations (XSLT) to repurpose your content for multichannel publishing. The best of them are part of a coordinated suite of tools that implement the many other options for XML development, which includes an alphabet soup of acronyms.
WYSIWYG. A simple XML Author tool that enforces the structural and styling constraints of XML schemas and XSL transformations can do this without revealing complex behind-the-scenes machinery. It should provide a comfortable and familiar interface for content creators used to working in standard what-you-see-is-what-you-get word processors. If the ratio of content creators to content editors and designers is high, you will need many more XML Author tools than XML Editor tools.
Validation. Guided writing, or structured authoring, works best when the writer is constantly assisted in doing the right thing. The ideal is continuous real-time validation against the content model rules in the schema. Even more rigid is to not allow the possibility of error. So validation comes in a range of settings. It can be turned off for experts. It may be done by clicking a request for validation. It may provide only warnings. It may actually correct or prevent errors. Some tools only allow both start and end tag sets to be inserted.
Elements in context. When adding structural elements, the best tools display a context-dependent list of the "allowed" or "available" elements that can be added at the current insertion point in the document. This can be in a separate window pane or a floating palette, a drop-down menu when you type an open tag, or revealed by right-clicking at the insertion point. Some Editors allow you to turn this down, or completely off for power users.
Tags-on view. Though they disrupt the pure WYSIWYG look, optional visual representations of the start and end tags for structural elements are very helpful.
Structure, or Tree, view. A hierarchical view of the document, which expands and contracts elements like an outline tool, letting you move around quickly in large documents. More powerful Editors let you move structural elements in this view and synchronize changes with other views.
Grid view. An arrangement of your content in something like spreadsheet cells. Cells can be moved, preserving their internal structure.
Drag/drop structure. The best Editors allow selection of the whole structural element, then drag-and-drop of the element—only to locations that are valid for the specific element, of course.
Source-code view. Some pure WYSIWYG Editors can show the source code for changes best made while looking at the XML source. Top tools highlight the syntax with your choice of colors so authors can easily distinguish the code from the content.
Tag auto-completion. When typing tags yourself, auto-completion is one way of enforcing correct structure.
Line indenting. Source code that is hard to scan quickly is useless. The best tools indent child elements to reveal the document structure. They may do this as you type or on-demand. But watch out for tools that add white space where you don't want them in mixed XML content. They should "roundtrip" your code cleanly.
XSLT processor. Built-in XSLT processing lets you view the multiple transforms to publishing output channels.
XPath/XQuery. Quickly find elements anywhere in a document that share a property and may be targets for special repurposing in your XSLT outputs. Some tools populate the XPath with your contextual position. As you click in the document your XPath appears automatically in the search box.
Native XML databases. Berkeley and eXist databases store your XML as is. Many content management systems do as well.
Specific schemas. Support for well-known XML "vocabularies" like DocBook, DITA, etc. Support also for different schema standards, like DTD, XSD (XML Schema Document), Relax NG, NRL, etc.
DITA. The Darwin Information Typing Architecture standardizes schema components that can be specialized to a variety of technical documentation needs.
DocBook. While DITA accomplishes most of what the SGML DocBook standard provides, some tools continue support for DocBook.
Package size. The amount of code downloaded gives you some idea of the amount of work put into these great tools.
Communities online. Judging a book by its cover is a bad idea, but listening to what users are saying about these tools is a solid criterion for judgement.
Google PageRank. Another objective measure of a company is its Google ranking on a logarithmic scale from one to ten. Note that every additional step up in rank means roughly ten times the importance of the site.
Templates. A library of "stationery" resources, XML documents that authors can start with, knowing they are valid for certain schemas and support specific output style sheets.
Developer tools. All our Developer tools can extract schemas from well-formed XML documents. Some offer visual schema designers. Some provide schema management to assist in the creation of compound XML documents that contain elements from diverse schemas and namespaces, e.g., Dublin Core, SVG (scalable vector graphics), MathML, etc. Some visual XSLT style sheet designers are synchronized with their code view. Look for new XSLT 2.0 support.
Spell check. This can range from simple checking with a customizable word list to dynamic word and phrase completion to insure that writers use terminology consistently throughout the organization.
Multilingual. Unicode support for integration with translation tools.
There are other important features you should evaluate when considering the selection of an XML tool; however, we didn't include these in our matrix because all 12 tools we evaluated have them.