XML Editors: Allegations of Functionality in search of reality

Search Ivritype for:

Editors explored

Clip 1.5

Homesite 4.0

Visual XML 1.1b

Xeena 1.03

XMetaL 1.0

XML Pro 2.0

XML Spy 2.5


Recommended by others
   WordPerfect 2000
   XML Notepad

If you have observations to add, please send me e-mail. Let me know if I can make your comments part of this page.

Other relevant pages on Ivritype:

Links to Online Resources

Note, 5 May 2005: I have not had time to re-evaluate this subject in over five years (although I have thought about it a lot) and don't see that time coming soon. I continue to use XML Spy and its pieces when I do XML editing and have not found anything to compare. I recently took Oxygen for a test drive, but it is horridly slow, and found an error in a schema that I was testing. In this case, the error appears to be Oxygen's. So I don't quite trust it yet. In the meantime, I got the following e-mail from the UK, and even though this new evaluation doesn't include my own preferred tool, it is current and covers a lot of good ground:

[Check out t]he article is at ahds.ac.uk/creating/information-papers/xml-editors/

It looks at 23 different editors and benchmarks them against various features (eg, Multilingual text input and display, Support for different schema languages)

It also presents the results of an evaluation exercise where different user groups tried a number of the editors.

The Arts and Humanities Data Service is, amongst many other functions, a national digital archive based at six different UK universities.

Alastair Dunning
Arts and Humanities Data Service

... and back to the 1999 article ...


The term, "XML editor" can refer to a great many types of tools, depending on the purpose to which the editor is to be put. Some criteria are described in this ZD Net overview: http://www.zdnet.com/devhead/stories/articles/0,4413,2138258,00.html

For a quick overview of most available XML editors, see http://www.xmlsoftware.com/editors/ (If you browse a bit, you'll also see some fuzzy categories on the site, which accurately reflect the current state of art.)

I have gone through several sets of criteria in reviewing software. In the end, this was the minimal, "this is what we really need":

  • The tool must be able to open up multiple documents

  • Find/Replace, including global, search a directory find/replace

  • It must show the editor relevant tags and make tagging easy

  • It must validate the results and make it easy to find errors.

  • It must be able to switch, update, or add DTDs later.

  • It must allow the creation and/or editing of well-formed XML documents sans DTD.

  • If the tool can accommodate at least some types of external entities, such as images, all the better.

In addition, the following are often important:

  • We also need a tool for creating, changing, and validating DTDs (the files that define XML document structure) and XSL (a method of merging XML calls with presentation information) documents. In other words, we want to not only edit documents, but edit the meta documents that describe how our documents work.

  • Because much XML editorial matter may be stored in a relational database, it is usually important that the tool make such queries easy.

  • The ability to edit tables may come to matter very much.

  • Ideally, the tool should be extensible, although what this means is also up for discussion.

And, finally, the tool must be robust. It must be easy to install, easy to maintain, and misfunction on the rarest of occasions.

At this time, XML editors do not tend to meet these criteria. Many are written in Java, which leads to some interesting, slow, and non-standard interface behaviors. I am not sure why this is necessary, but it is the current practice. (Many current editors, for instance, cannot handle path names, even on Windows 98/NT, that include word spaces. They also tend to first invoke DOS processes.). Then the better editors to betray their SGML roots (focus on document structure over ease of editing). Most, if not all, don't understand documents that are not XML (or something related, like HTML or SGML).

An obvious way around this problem would be to use a standard text editor with some XML plug-ins. The problem is that there are features that text-editors don't tend to provide, that are critical. For instance, the ability to see a DTD structure, to see what entities are permitted inside a document at a given point, or to validate the document prior to saving. This is an area where just being able to type or to click on tags is not as useful as it should be. In this, XML is much more akin to SGML, and unlike HTML at all.

At this time, it does not make sense to suppose that such an editor would be used for actual writing (as opposed to editing) on a regular basis. I expect people to use word processors such as MS Word or FrameMaker. (There are tools to go from RTF or FrameMaker to as specific DTD-generated XML document.)

There are three general categories of XML editor that were considered:

  • Freeware, simple editors
  • Database-derived (focus on modularity, ability to structure data from database)
  • SGML-derived (evidence of government committee specifications with an occasionally thinner than expected veneer of commercial usability)

I have encountered none of the enthusiasm for specific tools that foreshadowed the transition from editors to word processors (dig that Wordstar!), or that accompanied the rise in HTML (HomeSite! No, PageMill!). I have found no comparative reviews or links to favorite XML editors on the XML interest websites. Queries to XML lists garner, "well, did anyone respond to your query? I'm looking too" In part this means that good tools may not be out there. This may also reflect the fact that most XML is derived from other sources (databases, word processors), and little editing is done in XML, itself (excepting full-scale document management systems), at this time. Finally, it may reflect the fact that I am asking the wrong questions.

After posting the initial version of this document to the web, I did get several suggestions to try XML Spy, which I had not considered because earlier mentions referred to it as even less capable than XML Pro or Visual XML. Other suggestions included higher end tools such as FrameMaker+SGML, or use of the growing support for XML inside Word 2000 or WordPerfect 2000. We may eventually use one of the latest word processors, but what we really wanted was an editor. XML Spy, for now, is the current editor of choice (10/14/99), but we aren't going to stop looking.

Here is what I did find, and what I have concluded thereby. Note: All of this software runs under Windows NT (my testing platform) and Windows 95/98, unless otherwise specified.

Clip 1.5

Techno2000 USA, http://www.t2000-usa.com
Cost: $99.

Several folks doing general, minor XML hacking recommended this to me. It is a minimalist, comfortable interface in a style similar to that of XML Pro. It opened the test document with no problems, and was able to validate it. There was a comfortable, detached window to the side from which one can insert elements (style tags) and entities (things like "apostrophe" or "greater than").

Like XML Pro, this program does not appear able to open more than one document at a time. Like Visual XML, there does not appear to be a way to enable word wrap. There does appear to be a robust search mechanism, including the ability to search for tags, strings, and other document elements.

Upon loading an invalid document, I was unable to get the "component manager," the window that displays these entities and elements, to display anything. It is not clear if this is due to a problem with loading the document (no DTD attached at that time? reference to a DTD accessible via the web?), or the lack of validation, or due to a bug. Support has been queried.

Different from XML Pro, Clip contains a nice DTD editor, as well as the XML editor, and makes working on both relatively simple.

As was the case with XML Pro, this is a nice, simple, out-of-your-face editor that still lacks many features (word wrap, contextual entity listings, in this case) that would be considered sine qua non for production use.


EditML 1.0

Added to this page 11/5/99

According to the web page, "EditML 1.0 is a windows based editor for creating well-formed XML documents. The document can be a XML data file, schema file or a stylesheet. It is based on Microsoft's MSXML parser conforming to XML specification 1.0 (a W3C standard)."

It does not validate, and otherwise appeared a bit too simple for our in-house needs, based on what we saw on the website, so we did not download or test the software. The download is FREE.


Homesite 4.0

Allaire Corporation, http://www1.allaire.com/developer/HsReferenceDesk/
Cost: $89 (electronic) / $99 (CD ROM)

Currently my favorite HTML editor, and considered by most people who use it to be an extraordinarily easy-to-use and comfortable text-based HTML editing environment (as opposed to WYSISRTWYG, "what you see is somewhat related to what you get") HTML editors such as DreamWeaver or FrontPage. HomeSite also includes robust site management and find/replace tools that make moving an entire site, or performing global transforms on existing data quite easy.

Our initial hope was that it would be possible to edit XML inside the text editor already familiar to editorial and web development staff, HomeSite. Indeed, HomeSite provides an excellent platform in which to do general coding. It features color-coded components, the ability to tie in new toolbars, and the ability to read a set of potential tags from a DTD. Unfortunately, there is no way to drive XML context from within HomeSite. That is to say, there is no way to make it clear to an editor what tags can be placed inside what tags, and to enforce same (other than running a validator).

We do, in fact, have a toolbar that can be added to HomeSite that will validate documents to a given DTD, but, as attractive as HomeSite is as an editor, it adds nothing to the need to edit XML specifically. As a result of this review, I have also not placed other editors, used, say, by programmers (TextPad, UltraEdit, SlickEdit) on the review list.

We can use HomeSite, in lieu of a proper editor. It does enable placement of tags, we can have all of the tags in a DTD available on a toolbar, as well as access to a validating function, all from within HomeSite. But use of this editor will also highlight the need for a tool that makes the XML-specific functions as easy as more generalized editing.


Visual XML 1.1beta

Bluestone, http://www.bluestone.com/xml/Visual-XML/

Not sure what this really does.

This package claims to include an XML editor, a DTD editor, transform and database query tools, a Java editor and a SQL editor. My initial foray failed to provide information as to how to turn on word wrap for comfortable testing of the XML editor. Typical queries to the mailing list in support of the product seem to be "how do I uninstall."

Subsequent discussion with folks at the company revealed that the editor does not, in fact, support usual editing functions and is intended very much as an XML code editor, part of a very nice toolkit designed to set up XML-driven enterprise applications. I still think that there is a good set of tools here, but they are not relevant to this query.


Xeena 1.03a

IBM Alphaworks, http://www.alphaworks.ibm.com/tech/xeena

Testing incomplete

Xeena is the best looking editor of the lot, so far. Unfortunately, it lacks critical flexibility. For instance, to open a new DTD, you need to reinvoke the program from the command line, referencing the appropriate DTD. The installation does provide some pre-set-up DTD and profile editors, however, to simplify this somewhat.

Xeena can work with JDK 1.2.1 or 1.2.2, but isn't smart enough to figure out which you have installed, or where the one you specify resides. You use a "browse" button to tell the installer.

This editor was explored because several people mentioned its existence in relatively favorable terms. IBM alphaworks software are tools that IBM is developing, but for which there are no current marketing plans. You get the tool on a 90-day license, and then, presumably, re-download. When the tools are of this calibre, it is certainly worth exploring them, but this isn't the sort of editor I would hand over to staff and say, "have at it!" The alphaworks area is, however, a place to pay attention. The tools have lots of potential, and there is some sporadic conversation (would probably be better if based on useful conferencing tools, not Notes, but that is another issue) of interest to XML hackers.


XMetaL 1.0

Softquad, http://www.xmetal.com/
Cost: $495

On paper, this is the nicest commercial product for writing in XML that I have seen. The ability to do tables and to accommodate database queries is quite likely to be useful for some environments. It is the closest I have seen to an XML editor that looks and feels like a word processor, and shows that SoftQuad has learned some from their many years of SGML experience, and from their attempts to provide a consumer-oriented HTML editor (HoT MetaL, a program that I have tried to like through several iterations). There is a strong claim to customizability for this program, as well.

I downloaded the demo version of the program. I then launched it and did an initial test. This created two errors. Reporting those errors to SoftQuad got not response, and attempting to get a purchase price on the product from the website resulted in a "document not found" message when I clicked on the link to their purchase page.

The program allows multiple documents to be opened in a single window, using the "tab" approach also used by HomeSite and some other editors (different from opening several different, independently sizeable, windows). It offers three views of the document, one that attempts to render the information, one that shows all coding, and one that shows tags (sans attributes), but no other coding. These are nice, although it is unfortunate that the default "normal" display did not space between elements (e.g., paragraphs). That can apparently be modified.

The program did open our test document, reporting no errors. At first I wondered if that was a bug , as I was never able to get any indication that either rules checking or validation were working (this is one of the errors I reported to SoftQuad). My suspicion is that the DTD was accepted as valid without checking, but that the document was, in fact, validated against the DTD.

I also attempted to open a document that needed repair--it contained tags which were not part of any DTD. Xmetal insists on evaluating files that have the extension ".xml" as XML files (other types of files known to the editor are HTML and SGML). Once I changed the extension, the editor immediately noticed the XML declaration at the top of the file and again insisted on a valid DTD (which did not exist), without which it would not open the file. Attempts to comment out the XML declaration and the DTD declaration (which referred to a URL) both failed, as did the attempt to open a regular text file with no markup. The document could not be edited within Xmetal . So, we are caught in the XML editor trap--can't open the document to fix it in the editor. What do we do when we get malformed documents (other than fix them in some other editor)?

Relaunching the program after a first spin, I noticed that the program also opens whatever was open before. It doesn't remember what DTDs were assigned, so you must re-choose the DTDs, but there was no obvious way to stop the program from loading documents that had been live when I last quit. When using Xmetal, close all documents before quitting!

Other editing features are similarly not quite there. Using a default DTD that included an img tag, I attempted to load a graphic. Rather than a "browse" button, I found an attribute in which I was expected to type the address of the graphic. I found no aid in terms of "what tags can I use to start this document" or other contextual help.

A second set of attempts to get support got a suggestion that I remove the program, reinstall, and start again. This was duly done with similar results. I have queried further to see if there are incompatible JDKs, MDAC components, or other components installed that might be causing this problem.

If this program worked as advertised, it could be useful, but I am not sure that we can make that assumption. Rather, Softquad appears to be trying to make XML look like Microsoft Word when they perhaps should have been trying to write a bulletproof XML editor.


XML Pro 2.0

Vervet, http://www.vervet.com/
Cost: $150/downloaded online; $175 CD ROM

This tool was reviewed positively by ZD Net (version 1.2), and linked from other XML resource sites such as Café con Leche. I first ran into the tool on XML-L. When I spoke with the Vervet staff about the difference between their product and, say, Xmetal, I was told: "when you purchase Adept or Xmetal, you are paying for a lot of legacy SGML code that you'll never use."

In common with Xmetal, this program is limited to XML documents for which it can find and validate a DTD. The XML document, itself, must be well-formed; mistakes must be fixed elsewhere, first. You can have only one file open at a time, and you cannot open anything but an XML file.

A call to their support phone number got a prompt, useful, detailed, and courteous response, despite the fact that I am not a registered user.

The editor window is unusually clean, and a pleasure to work in. But, even here, I was frustrated. I wanted to use our Network World DTD to construct a test document, but I couldn't associate a DTD with a document without saving the document, which I couldn't do with the demo version that I initially downloaded. Once I downloaded a 30-day full demo from another source, I was off and running.

This was really the first "XML Editor" I had used. That is to say, I hadn't yet considered what might make an XML editor different from any other text editor. The difference becomes quickly apparent when you edit a document, or even better, when you start a document from scratch.

The core program consists of three windows (plus, optionally, windows with both the elements and entities; in real life, both are necessary). To start a document, you specify a starting element (usually the starting element in your DTD, or DTD-to-be-associated, such as "CONTENT" or "ARTICLE." (First complaint: Why can I not first load a DTD and work from it. Why must I start a document, associate it with a DTD, save it, reopen it, and then continue?).

So, there you are staring at a screen with small, detachable element and entity windows to one side, and the three part main screen, which consists of a vertical, narrow panel (listing of elements and entities), a top right-hand "contents of the entity" panel in which you check, enter, or edit attributes, and an "editing" panel in which you type your content.

So, to begin my article, I added an "ARTICLE" element and filled out relevant attributes in the top right screen. Now I want to continue. I need to click on the next element, say, "BYLINE" or "BODY". So, I add a "BYLINE" to the article. But, where do I type what the byline is? What does a byline hold? PC DATA. If I then add PC DATA to the byline element, I can finally type my byline into the editing area on the bottom right third of the main window.

This sounds complicated, but has advantages:

  • You can always see the document structure
  • You can always see what can be added where
  • You never lose sight of the fact that you are working with XML-structured text.
  • Once you know the structure (5 minutes of poking, or 5 minutes of training), the editor is exceptionally easy to use.

Yet, after all this, I was unable to validate the document I created from scratch.

Summary: Exceptionally clean editor. Very easy to install, learn and use. My major complaints are the inability to start off using a default DTD, and the fact that only one document can be open at a time. I'm also not convinced that validating works.

Reviews: http://www.infoworld.com/cgi-bin/displayArchive.pl?/99/36/i03-36.41.htm


XML Spy 2.5

Icon Information-Systems, http://www.xmlspy.com/

After publishing the first iteration of this page, several people wrote to suggest that I review XML Spy. I'm glad they did. This is the first editor I've come out of the review process liking.

For starters, this is the first editor I've installed whose installer asked normal things like, "would you like this to be your default XML editor" and "would you like a shortcut on your desktop." Usually the assumption is "yes" and "yes," with no question. (For now, of course, the answer was "no" and "no," but so be it.)

The manual is in Adobe Acrobat form, which usually a good sign--it means that someone tried to document the program, as opposed to stringing together incomplete help files. The documentation was, in fact, quite readable and clear. It lacked only an index, apparently assuming that the "search" button would suffice. (Bad assumption--professional indexing matters, even in a small, 60-page manual.) But, compared to the competition, this is quibbling, the difference between a "9" and a "10" rating.

In opening the first test document, this is the only editor so far to spot the two "curly quotes"-non-ASCII, typographically correct characters inserted by someone's editor and not caught during any of the subsequent cleanups. I was given no easy way to map the characters to appropriate entities, but I was given the hex values of the offending characters, and was quickly able to clean this up. Using Find/Replace on these within XML Spy was intuitive. The one worrisome note is that both quote characters were converted (for display purposes only, I thought) to an open box (often used to display non-printable characters). By copying the box and pasting it into the "find" window, then typing my double quote character into the "replace" window I effected the change--but I got both characters with one pass, indicating that all had been munged in the same way. This is an easy way to get into trouble (what if not all of the changed characters had been double quotes--what about apostrophes or em dashes, to note two other common sets of artifacts found in word processing docs converted partially to ASCII). I should note, of course, that I could have paged through the file, replace by replace, rather than doing all at once.

Editing the test document was trivially easy. I shouldn't be giving the program points for following normative interface guidelines, or for making it possible to edit in ways that follow how one normally edits, but such fine points have been lacking in other tools. So, having opened the document and gotten the view of the document text (in a left-hand pane I have the document structure), I moved the text insertion pointer to the appropriate location with the mouse. Clicked, and began typing. While working, the element I was editing was highlighted, although to what purpose I am not sure (to remind me that I was editing a specific element?). Drag and drop editing is featured for elements, and the user is prevented from dropping elements into places where they cannot fit. One cannot drag and drop highlighted snippets of text, however.

Curiously, one cannot view a list of legal elements or entities while editing (or even, of elements overall), or view the DTD. One can, in fact, insert any element into the document while editing. XML Spy references the DTD on opening a document with a reference to a DTD, and then leaves you alone until you go to validate the document. The program will then show you where mistakes have been made, if they have been made. It would still be very helpful to have the lists of elements and entities, and better yet, allowable elements and entities based on the current insertion point, but this is really the only major complaint against this program. (It is a major complaint, though.)

XML Spy allows you to view the document three ways, a source code view, a structured view, and a visual form dependent on tools in IE5. This is quite welcome.

XML Spy has no problem with external DTDs and happily opens multiple documents, each in its own window (similar to MS Word, whose RichText editing tools it borrows), or, if you have windows fill the entire screen, accessible from the "view" menu. XML Spy can also be used to edit DTDs. I found no useful way to use XML Spy to incorporate images (presumably, if one has an img element, you type in the reference--I did not test this, however--and there is no drag and drop, or nice browse feature to help you locate an image or other binary object), nor is there any inkling of a table editor. There are no advanced tools, such as the ability to query SQL.

Summary: This program is exactly what it claims to be: an excellent, simple editor. We intend to use it in the department for a while and see if it takes.



These are really bad. Several companies have no e-mail support worth speaking about. Several editors found the ability to wrap lines (aka "word wrap") exotic, as did a second set of editors for whom having two or more documents open at once was too much to ask. Several people have written to ask about support for XML in Word 2000, WordPerfect 2000, and FrameMaker+SGML, all of which are probably okay to great for document processing, but are all a bit much for our needs. We wanna open docs up, tag 'em or fix 'em, then move on.

Having said that, the winner is a cross between XML Pro (list of elements and entities, as well as contextual lists of same) and XML Spy (all the basics excepting that one major feature). We won't be thrilled, but since we can teach the editors the basic tags they need to use better than we can show them how to attach DTDs to XML Pro docs, and we can deal with that better than the current inability of XML Pro to handle more than one document, that's what we'll probably use. Or, we'll give people the option to have both, and they'll let us know which they're still using at the end of 30 days. Overall, XML Spy is just over the line on usability; XML Pro almost there. Stay tuned. Hopefully, there will be reason to update this page positively over time.


Other folks chime in

Most of these comments were sent to the general XML-L mailing list, and more info can be found by searching that list's archives.


Lennart Stafflin, http://www.lysator.liu.se/projects/about_psgml.html

.... To check it out, see the "Editing SGML Documents with the Emacs Text Editor" chapter of my "SGML CD" book. The chapter is available for free as an Acrobat file at http://www.snee.com/bob/sgmlfree/. It assumes no previous knowledge of Emacs, and everything in it applies to XML as well as SGML.
Bob DuCharme
13 Oct 1999

[In response to my questioning an earlier mention of these editors on the XML-L list. ari] ... PSGML comes up on the XML-Dev list very often; XED somewhat less so (the Python curse).  As Bob (I think) pointed out, these are not editors for naive users, but they're extremely powerful in the hands of an experienced user, and I think that PSGML, at least, easily meets all of your original criteria; besides, it was the first XML editor, as far as I know.

PSGML has been under development in one form or another since 1992 (originally as an SGML editor).  I used it quite extensively and successfully with the full TEI DTDs -- probably the hairiest document type(s) ever created, and ones which forced all kinds of patches and work-arounds from the commercial editor vendors.

David Megginson


Tetrasix, http://www.tetrasix.com/

At the University of Iowa, in their pilot project for Electronic Theses and Dissertations, the graduates --with limited prior experience with markup, if any-- had very good success with Tetrasix's Majix.  There is a free version which is customizable as well (at least the one we used was), it requires that the JDK 1.1.7 be installed, but this is fairly easy and I can provide instructions we wrote for the non-technical if needed).

Majix is quite a spiffy tool.

John Robert Gardner
13 Oct 1999

WordPerfect 2000

Corel Corp, http://www.corel.com/

... I've tried several of the products you mentioned (including HomeSite, which I use for raw HTML editing) but am not crazy about any of them.

I have, though, heard very good things about WordPerfect 2000 as an XML editor. As an old WP user, I expect that will be what I'll end up using.

Part of the problem in evaluating such tools is defining the user base you're interested in. A user who's greatly interested in seeing a document's structure is likely to be annoyed by something that looks too much like prose with embedded angle brackets. Someone whose notion of an ideal editor equates to a word processor will probably be quite distressed by the two- or three-pane windows that many of the current XML editors use (element tree to the left, content to the right).

This may shake out a lot more easily when (if) editors become capable of reading and applying style sheets, XSL and/or CSS, as well as source documents and DTDs.

John E. Simpson
13 Oct 1999

Emilé 1.0

Media Design in-Progress, http://www.in-progress.com/emile/?id=3PEG0
Cost: $39, Macintosh only

I would be remiss if I did not refer you to Emilé and/or XPublish from Media Design in-Progress.  It addresses many areas you've mentioned.  Be sure and look at the Pro version, as it provides tree views as an option, context identifiers, extensibility with user-programmed tools (in lisp), and many other features.  It's part of a suite which also has a CSS editor for getting your XML browser-ready in a refreshingly easy GUI environment (CSS editing is bundled with XPublish, but separate from Emilé Pro). Emilé Pro is currently the most up-to-date tested of their XML editors, and the one I best recommend for your comparison

Its ONLY caveat is that it is Mac only-- but rumor has it they'll port it over to Windows with a modest up-front commitment of interest and, perhaps, cash.

John Robert Gardner
13 Oct 1999

InfoWorld Review of XPublish 1.0 (the software is now at 2.0), April 27, 1998, http://www.infoworld.com/cgi-bin/displayArchive.pl?/98/17/iw03-17.84b.htm

XML Notepad Beta 1.5 and VIM (VI IMproved) 5.5

Two simple free editors:

M.T. Carrasco Benitez
14 Oct 1999


Thank you for visiting http://www.ivritype.com/xml/index.html
This page is maintained by Ari Davidow, ari@ivritype.com. Copyleft Ari Davidow, et al, 1999.
Originally posted 12 Oct 1999. Last revised 05 May, 2005.