When first evaluating WYSIWYG XML editing or XML form tools, it is hard to even know what questions to ask, let alone what the answers are for each of the many options out there. This document is an attempt to provide some guidance on what features to look for and what questions to ask, as well as to share some hard-won insight gained from getting my hands dirty with various of these products.
There are so many ways to classify WYSIWYG XML editor applications, that I had better lay some ground rules on what kinds of products I mean to include in this report and what kinds of products I am trying to avoid. All of the products have the following in common:
Conversely, I do not mean to include any products from the crowded class of WYSIWYG HTML editing widgets, unless they specifically provide some generic XML editing functionality (even if only recently introduced).
All text in this document, unless clearly quoted, consists of my own comments based on my experience with these products. In cases where I did not have time to explore a certain feature or product myself, I defer to the published vendor's product information and make it clear that I am quoting from their Web site rather than reporting on my own experiences.
How to distinguish between lightweight and heavyweight? Perhaps I should focus on browser-based or not, instead. For the sake of argument, I'm coming up with these classifications so far (without any particularly good reasons that I know of yet):
Perhaps the distinction comes along the document-oriented vs. form-oriented axis. Some tools lean in one direction more than the other, while some provide equal support for both. Another useful dichotomy is HTML-oriented vs. generic XML-oriented.
Potentially useful dichotomies (don't necessarily try to fit all tools into each dichotomy; sometimes it will just not apply to a particular tool):
Some tools, such as eWebEditPro+XML, include custom XML tags interleaved and embedded in XHTML as a way of editing XML in the context of an XHTML-based view. The pure XML instance is imported on load via an XSLT transformation to the editing view and is exported on save to an XSLT transformation to the pure XML instance. The XHTML + custom tag approach, while not the most elegant environment to operate within, does provide transparent scripting access to all aspects of the display, regardless of whether they are purely formatting elements or actual XML content. So you have to do more work up front (two XSLT transformations), but you get more flexibility in certain areas.
Other tools, such as Authentic 5, provide a higher-level mapping between XML elements and HTML elements and form controls (using a syntax that mechanically converts to a subset of XSLT) that determines how the editing view looks. This single mapping provides round-trip import/export of the pure XML and thus does not require separate onload and onsave XSLT stylesheets. The scripting access is to the "pure" XML object model, devoid of the HTML formatting. While in some ways this is more elegant and less work to get up and running, it generally proves to be less flexible in terms of what behaviors can be effected in the live editing view.
To some extent, this differentiation betrays the history of these products. While Authentic was built from the ground up as a generic XML editor, eWebEditPro+XML has an HTML-only ancestry, succeeding its predecessors with the addition of "+XML".
[browser-based] WYSIWYG X[HT]ML [document|form] editing tools
Technical feature matrix (not always entirely objective)