This is a read-only archive. Find the latest Linux articles, documentation, and answers at the new!


Open source XML editors examined

By Ryan Paul on February 28, 2005 (8:00:00 AM)

Share    Print    Comments   

The eXtensible Markup Language (XML) provides a flexible and efficient way to store, transmit, and express data. Many applications have adopted it as their sole data format, and the availability of comprehensive XML development libraries makes it easy to add support for XML to new and existing applications. The open source community has produced an impressive lineup of XML editing utilities. In this article we'll take a look at some of the most useful.

Despite the numerous benefits of XML, users and developers that work with it realize that XML's versatility is a mixed blessing. How does one design an effective editor for a data format that can be used to express virtually any kind of structured content? A visual editing idiom that is appropriate for developing a user interface with XUL content may not be appropriate for writing an essay with DocBook content. In many cases it becomes necessary to construct a specialized editing environment that provides a unique interface and produces valid XML code, such as Glade or

If one were to build a generic XML editor that could support a multitude of vastly disparate content types, how would it work? The structure of a given XML content type is usually specified in a Document Type Definition (DTD) or a Schema. An application can use this data to introduce specializations and interface refinements. Many XML editors employ document meta-data to provide context-sensitive assistance and automation mechanisms.

KXml Editor is a lightweight XML editor and viewer that interfaces exceptionally well with other KDE applications. You can configure Konqueror to use the KXml Editor KPart as an XML view interface component. With its extensive assortment of excellent keyboard shortcuts, KXml Editor facilitates rapid development of data-oriented XML content. Input of element character data requires the user to employ a textbox dialog window that decreases the fluidity and efficiency of the editing experience. KXml Editor allows the user to utilize XPath nomenclature to select a single specific node, but it does not completely support the XPath query syntax, and queries that target multiple nodes are presently ignored. KXml Editor provides no support for content processing or validation, and it cannot open XML documents that contain syntax errors. KXml Editor is usable and efficient, but its limitations decrease its value as an editing tool. It is my XML viewer of choice, and it is useful for rapid production of simple XML documents, but it is less efficient than a conventional editor for DocBook authoring.

Bluefish is a powerful Web development environment that supports a number of markup and programming languages. Despite its extensive feature set, it doesn't provide much support for XML yet. Bluefish has a built-in project manager and an extensible build system that works well for Java and C projects. The intrepid user will easily be able to configure Bluefish to support external XML validation and processing utilities. Bluefish has an impressive function reference system that greatly expedites development of Python and PHP. Unfortunately, it does not provide support for XSL. Bluefish is a great tool for diverse development projects that encompass multiple technologies, but its not the best solution for typical XML authoring tasks.

Quanta is an extremely powerful and extensible Web development environment that has excellent support for XML editing, and provides users with several ways to extend its abilities. Quanta has a nice project manager and a great interface. Quanta's editor supports folding, syntax highlighting, context-sensitive tag completion, and automatic tag closure. Quanta has a built-in XML validation utility, and a really cool XSL debugger that supports breakpoints and stepping. It has a decent template system that automates creation of a wide variety of document types (including DocBook) and it can create new custom templates that you can save for global use or associate with a particular project.

You can use Kommander to write powerful graphical script utilities that extend the functionality of Quanta. Quanta's versatile action system lets you associate Kommander scripts and XML tags with keyboard shortcuts, menu items, and toolbar buttons. You can create more sophisticated extensions as KParts and integrate them with Quanta through its plug-in interface. Quanta comes with plug-ins for CVS management, multi-file search and replace, image map editing, link analysis, and XSL debugging. It is even possible to integrate KXml Editor into Quanta as an additional document view. Quanta has a tag attribute editor, and a tag tree interface that lets users efficiently navigate large documents. Quanta's elegant split WYSIWYG mode makes Web development a pleasure, and its highly configurable editor component and action system allow users to effectively utilize both the keyboard and the mouse.

Screem is an effective Web development environment that is simple and powerful. Its interface lacks the refinement of Quanta or Bluefish, but it is moderately innovative, and provides some unique advantages. Screem supports context-sensitive tag completion, brace matching, real-time validation, and a unique, intelligent tag closure system. I was particularly impressed with the real-time validation mechanism, which highlights any content that invalidates the document.

Screem is not as customizable as Quanta or Bluefish, but it has a text insertion macro feature, and a system that enables users to add external commands to the menu. It has an integrated symbol viewer and a function reference interface, neither of which impressed me. The symbol viewer doesn't seem to work with C or Python, and the reference system implementation is poor. In addition to the traditional text view, Screem has a tree view that displays document structure, and an attribute input interface that provides a complete list of valid attributes associated with the currently selected tag.

As a Vim user, I tend to dislike the limited potential for customization that plagues modern development environments. I shudder at the prospect of using an editor that doesn't allow me to dynamically add new features at run time. Vim customization is really more of an art than a science. Experienced Vim users like to do things their own way, with whatever scripting language they feel most comfortable with.

Tobias Reif has produced an excellent guide to XML editing with Vim. It is a must-read for any Vim user interested in XML development. In his guide, Reif shows how users can leverage Ruby scripts and third-party command-line utilities like Jing and XMLStarlet to construct a complete, versatile XML authoring environment.

Emacs users may be interested in nXML mode, which provides Emacs with an assortment of nifty XML authoring features, like context-sensitive tag completion, intelligent tag closure, and real-time validation. It also provides several useful keyboard shortcuts that simplify moving around XML documents. nXML mode employs Relax-NG (RNG) schemas rather than DTDs. RNG is a powerful and flexible schema language based on TREX and RELAX. The limited availability of existing RNG schemas diminishes the usefulness of nXML in some contexts, but for DocBook editing, nXML is a good choice. Emacs users may also be interested in XSLT-process mode, which adds XSLT processing and debugging to Emacs. The XSLT-process-mode debugger supports break points and stepping, and displays XSLT stack frames and variables in the speed bar.

For unique insight into the future of XML editing, take a look at Conglomerate, an innovative XML editor that features a creative interface particularly suitable for DocBook authoring. Conglomerate uses nested boxes to represent the document structure, and between-line annotations to indicate the presence of inline tags. This unconventional and intuitive presentation manages to remain unobtrusive, and conveys a lot of information about the content of the document. Conglomerate uses DTDs to provide element insertion context menus. Users can customize Conglomerate's view interface with specialized display specs and external plug-ins. Yet despite the quality of its interface, Conglomerate still needs a lot of work. The rendering engine is far too slow, and the application lacks stability.


All of these programs lack XPath support. Users should be able to utilize XPath for filtering and programmatic manipulation of document content. Many of the programs support a multitude of other technologies at the expense of better XML support. The tools designed exclusively for XML either have mediocre interfaces or lack performance. Despite these deficiencies, some of these applications are superior to expensive proprietary alternatives such as Softquad's XMetal and Wattle's XMLWriter.

Share    Print    Comments   


on Open source XML editors examined

Note: Comments are owned by the poster. We are not responsible for their content.


Posted by: Anonymous Coward on February 28, 2005 07:13 PM
jEdit with the XML & XSLT plugins is a very powerful editor as well



Posted by: Anonymous Coward on February 28, 2005 11:08 PM
jEdit<A HREF="" title=""></a> with its plugins
for XSLT, XPath, XQuary, XIndent, XMLInsert, SlideKick, Structure Browser, etc. is really one of the best opensource xml editor.


Posted by: Anonymous Coward on February 28, 2005 08:33 PM
Alternative view at <A HREF="" title=""></a>


You missed "Pollo"

Posted by: Anonymous Coward on February 28, 2005 09:29 PM
You missed Pollo at <A HREF="" title=""></a>.



Posted by: Anonymous Coward on February 28, 2005 10:37 PM
I agree with other posts. The article does not mention a number of existing editors. Some of them might not be open source in sense that they are the effort of a single author.

Check:<nobr>e<wbr></nobr> ditors.html



Posted by: Anonymous Coward on March 02, 2005 12:46 AM
"Some of them might not be open source in sense that they are the effort of a single author."

What the fuck 'ave you been smokin, mate? Open source applies to projects whether they have one author or a million.


Still waiting

Posted by: Anonymous Coward on February 28, 2005 11:01 PM
Too bad but the open source XML editors seem to be too far from the proprietary alternatives like Stylus Studio, Oxygen or Exchanger. And it is worse that even in the commercial editors available for Linux the GUI interface is often far from that of the Windows version (Oxygen ain't too bad, however).

Yes, there may be some primitive commandline tools for most if not all XML related things available, but what about an integrated and preferably GUI-based all around professional level editor that could really ease your job with XML, and that has validators and support for more than one standard? It seems to me that there could be a market for this sort of an open source XML/XSL/schema editor for Linux.


Re:Still waiting

Posted by: lahvak on February 28, 2005 11:27 PM
Great idea! Get to work!


Still waiting-Moochers.

Posted by: Anonymous Coward on March 03, 2005 09:31 AM
"Great idea! Get to work! "

Don't forget to release the source code so we all can mooch off you.


Wrong link?

Posted by: Artis Rozentals on March 01, 2005 01:18 AM
The 'XSLT-process mode' link leads to, I don't think that it's the correct intended destination.


Re:Wrong link?

Posted by: Anonymous Coward on March 02, 2005 06:16 AM
Right link is probably <A HREF="" title=""></a>


You also missed Vex

Posted by: Anonymous Coward on March 01, 2005 01:28 AM
You also missed <A HREF="" title="">Vex</a>.


Don't Worry...

Posted by: Anonymous Coward on March 01, 2005 05:38 AM
To Ryan Paul and authors of other articles like this: Don't worry that 90% of the posts on articles like this are "Yes, but you forgot [my favorite]." Most people may have heard of one or the other, and maybe even tried more than one. But it can be suprisingly difficult to round up a healthy set of tools (either via Google or SF). You usually get way too many hits to click through and explore. Of course the additional tools mentioned in the posts just help round out the field for those, like me, who use XML occasionally and may not have heard of most of these editors.

I like articles like this where someone who knows a lot more than I do gives a breif overview of several items, whether they miss l337snarkyH4X0r's favorite or not. Keep up the good work.

P.S. No offense to those of you who post about your favorite being left out. The follow-on posts are good at rounding out the field, but can seem a bit discouraging to the author.


Re:Don't Worry...

Posted by: Charles Tryon on March 01, 2005 06:52 AM
I would worry less about offending the author and more about providing real feedback about what editors people are actually using. I have spent some time looking for a GUI based XML editor, and found that I quickly got lost in the huge number of projects out there. Unfortunately, it seem like the majority of these editors are either abandoned v0.5 versions of someone's pet project, or severely limited in their flexibility, or hightly dependent on the environment. Looking at this article, the editors mentioned might be useful if you are (a) doing Web development, and (b) using KDE as a desktop. Unfortunately, that sort of makes them useless for me.

What I need is a fairly generic, validating editor that will run without forcing me to install another 15 RPM packages. I actually had an older version of the oXygen editor and liked it, but the commercial license didn't include any version upgrades, so I'm sort of out in the cold for that one. What I need is a list of currently maintained editors and how different people have been able to use them in real life situations.


Re:Don't Worry...

Posted by: Anonymous Coward on March 02, 2005 02:27 AM

These lists of XML editors could help:

<A HREF="" title=""></a>

However, as you mentioned yourself, Oxygen seems to be the top choice as a general full-featured all around XML editor for Linux currently. I'd be happy to use it too, and wouldn't mind the proprietary license otherwise but too bad if you can't get free updates even if you buy a copy of it. I don't have the money to buy constant updates. So it has to be some other choice for me it seems.

Currently I tend to use various smaller and specialized tools for different tasks. Vim or Emacs might suit some people very well too, but I am not that much into commandline tools.


screem symbol browser

Posted by: Anonymous Coward on March 01, 2005 10:14 PM
The screem symbol browser relies on a system having ctags installed. without it no language is supported by it, with it, C, Python, PHP, etc. are all supported.


I favor extensibility over specific features

Posted by: Brian Masinick on March 02, 2005 06:40 AM
I favor extensibility over specific features. As a result, I tend to favor the classic editors. I'm partial to GNU Emacs myself, but I am not an Emacs bigot, I use Gvim, Jedit, Nedit, and many other editors to solve specific problems. I even use ed every now and then when I want to solve a specific problem in a script and I don't feel like using Sed, Awk, Perl, or one of the other tools. There are LOTS of ways to solve editing problems. Editors that offer specific features are great, but only if they can be extended.

The one thing that this article demonstrates well is that no editor does everything possible right out of the box. The writer likes Vim because he can customize it and get it to do anything he wants it to do. Followers of Jedit feel really strongly about the same thing. Any mention of flexibility without mentioning Emacs would get people up in arms. But there are many other very good editors, and many other very good scripting tools that can be combined with other tools to provide editing functions.

Without a doubt, trying to solve all problems with a single tool is the sure way to add to the length of a project. Use what works and spend a little time when you get an idle moment to experiment. Then when things get hectic and busy, you can use all the tools of your arsenal.


File Types

Posted by: Anonymous Coward on March 03, 2005 10:05 AM
The idea of a truly all-purpose storage format doesn't jive with me. I like seeing a text format that can do a lot, but you have to be careful about sacrificing simple and elegant design for overly complex capabilities. I'm not going to care that my video format can also run a server for my blog if my video is jumpy because of the extra capabilities (extreme example).

While there are advantages to an all-purpose format, I think it's still important to have simple formats that do their one task and do it well.


lacks many tools, wrong conclusions

Posted by: Anonymous Coward on March 04, 2005 07:40 AM
It lacks mentioning many other open source
tools which deserve to be in such article.

Ex: How about XML editing in Eclipse?

Another note:


>All of these programs lack XPath support. Users
>should be able to utilize XPath for filtering and >programmatic manipulation of document content.

Did the author actually evaluate the tools mentioned in the article?

Ex: XmlStarlet from the
article does exactly that.


XML is a horror

Posted by: Anonymous Coward on March 05, 2005 12:20 AM
There are plenty of other formats that are plain text editable, and does not have the unneeded complexity of XML. No it is not easy to store transmit, work with etc. compared to the alternatives<nobr> <wbr></nobr>....


XML document entry

Posted by: Anonymous Coward on March 05, 2005 12:56 AM
This article addresses one aspect of XML: that of a developer editing data-driven XML. What I am more interested in is actually document creation, from simple in-house memos, to fully pubishable books, user's guides, magazines. I have created a simple XLST-based processing system that can render the source XML document into PDF, TXT, HTML, etc. But the fact that the document must be written in a text editor and then marked up is a huge impediment to general use (regardless how nice the text editor's XML plugin is). Only a developer has the text-editing acumen to make it useful (hell, even web developers seldom manually markup their HTML!). I'd like to see a WYSIWYG "word processor" that loads a DTD or CSS and allows user to select styles from the DTD to apply to their text -- but never have to see the actual markup. Then their documents can be treated as source: machine readable, searchable, parseable, renderable. My vision: Noobs creating true XML documents! So far i haven't seen it. Not in Word, not Open Office, and none of the text editor plugins. They're focused on easing the manipulation of tags -- folding, hiding, etc. But nothing that really resembles the WSYWIG word processor that Noobs are used to (and still struggle with).


Re:XML document entry

Posted by: GrahamH on March 10, 2005 11:07 AM
> I have created a simple XLST-based processing system that can render the source XML document into PDF, TXT, HTML, etc.

Me too! Fun, ain't it<nobr> <wbr></nobr>;-)?

> I'd like to see a WYSIWYG "word processor" that loads a DTD...
> My vision: Noobs creating true XML documents!

Again: me too! Although I'd go easy on the "Noobs" label<nobr> <wbr></nobr>;-)... I'm also dreaming of a schema-aware validating XML editor that uses CSS to style its "WYSIWYG" view... I've seen some editors come close (Morphon:, but nothing yet that really nails it for me (although, personally, I'm happy with a tagged view; so when I'm not using proprietary editors, I "get by" with the excellent jEdit with plugins).

I'm also dreaming of an SVG editor that shares the same CSS as the text, with both text and graphics folded into XSL-FO for processing by, say, Apache FOP... Inkscape looks promising, but I'm currently baulking at cutting my CorelDRAW umbilical<nobr> <wbr></nobr>:-).

I remember the days when anyone inside the organization I was working for could log on to a (mainframe) terminal, and use the same (GML) format to write design documents, user documents, presentations... you name it. All without purchasing licenses for "third-party" software. Single-sourcing, or at least source re-use, was straightforward.

These days, documentation and presentation formats seem to have, er, "bifurcated", making single-sourcing and reuse (between marketers, product designers, and "user assistance" specialists, aka "technical writers") much more difficult.

My vision: open source, multi-platform "WYSIWYG" XML text and (SVG) graphics editors on every desktop (schema-wise, for text, I'm pinning my hopes on DITA), with the XML source stored in a "revision control system" (Subversion?), and automated (Ant-driven?) scripts (using XSLT, with "procedural glue" in Java, or some open source scripting language, such as Perl or Python) to produce various output formats, including PDF (via Apache FOP) and Eclipse Infocenters (which seems to me the best open source method for producing something equivalent to Microsoft's MSDN Library... I'd love to see Infocenters with a semi-Wiki-style collaborative review feature). The same scripts should be available to users for ad hoc, "on demand" formatting (say, via "right-click" shortcuts on the desktop), and also run on servers in automated product builds or as regularly scheduled tasks (say, overnight, to update intranet/Internet sites).

I've gotten most of this working already (with some ugly kludges along the way): the biggest missing piece seems to be a nice, document-centric, open source XML editor.


Open source XML

Posted by: Anonymous [ip:] on September 29, 2007 06:50 AM


This story has been archived. Comments can no longer be posted.

Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya