Your support for our advertisers helps cover the cost of hosting, research, and maintenance of this FAQ
Hundreds, possibly thousands, of programs. Details are no longer listed in this FAQ as they are now too many and are changing too rapidly to be kept up to date: see the XML Web pages at http://xml.coverpages.org/ and watch for announcements on the mailing lists and newsgroups.
For a detailed guide to some examples of XML programs and the concepts behind them, see the editor's book (Flynn, 1998). There are several implementations of the key XML processing and query languages (XSLT2, XQuery, and XSL:FO), the most popular of which is probably Saxon.
SGML software such as Jade and SP (now OpenSP) remain the source of several utilities which also handle XML, especially the onsgmls validating parser and sgmlnorm (see Converting valid HTML to XHTML).
Details of some XML software products are held on the XML Cover Pages. For browsers see the question on XML Browsers and the details of the xml-dev mailing list for software developers. Bert Bos keeps a list of some XML developments in Bison, Flex, Perl, and Python. The long-established conversion and application development engines like Omnimark, and SGMLC all have XML capability and they all provide APIs.
Choosing an editor is one of the hardest tasks, because everyone has different requirements and levels of knowledge, and what appears to be incredibly simple to one user may seem dauntingly difficult to another. All XML editors guide the user in the construction or maintenance of XML documents — that's their purpose in life.
The simplest ones just keep track of matching pointy brackets, start-tags and end-tags, and balanced quotes, leading to a well-formed file. More powerful editors can read a DTD or Schema and provide menu choices for element manipulation and attribute editing, and prevent the creation of invalid documents. The most powerful ones can also be used for DTD or Schema development, and for XML processing with XSLT or XSL:FO.
Some are text-mode editors — they show all the markup and the text with nothing hidden, often using colour to distinguish markup characters and indentation to show the structure. Most editors have a synchronous typographic mode as well, using a stylesheet to format the display, so you appear to be editing a fully typeset view of the document (often called WYSIWYG, although it's actually not). Text-mode editors worry some users because the pointy brackets are visible (they think it's programming); synchronous typographic editors worry other people because the pointy brackets are not visible, which makes it hard to see where stuff begins and ends.
Do not be tempted to use a non-XML editor like Notepad, vi, or textedit for XML documents: it will only end in tears, anger, and recriminations. Get properly-equipped. (Microsoft's separate XML Notepad product is usable for editing small instances, but not for DTD or Schema development.)
Wikipedia has a comparison of editors at http://en.wikipedia.org/wiki/Comparison_of_XML_editors but it doesn't give any qualitative information. There is an old (2004) comparative paper on choosing an XML editor from Thijs van den Broek which may help with methodology although the products are not current.
Several of the editors are available free of charge or free for demo/examination, but as far as is known, the only entirely open-source one is Emacs with nxml-mode (for W3C and RNG schemas) or psgml-mode (for DTDs).
Michael Sperberg-McQueen writes:
Choose your editor carefully
(Experienced computer users should also read Michael Sperberg-McQueen’s very sensible and relevant comments)
Twenty years ago, when my computer center required us all to start moving our data from VM/CMS to Unix, and we were all trying to decide which of the available text editors to invest time in learning, I formulated one of the few general principles of computer usage that has ever been revealed to me:
If you are a serious computer user, you will spend more time in your text editor than in any other single application. Choosing well is a good idea.
It takes a long time to learn an editor well. You will not learn 2000 editing programs between now and the day you stop using computers at all — you may only learn two or three. Choosing wisely is important to avoid wasting time.
The first question to ask, when considering any candidate editor, is ‘when I write a macro for this editor, what is the name of the language I’m writing in?’
There are three classes of answer:
Answers of the form ‘you don’t, there are no macros in ———’. These won’t normally occur, since such editors won’t ever actually be candidates for serious day-in day-out use.
Answers of the form ‘It’s a specialized macro lang-[…]’. You needn’t listen to the end of these; the editor is not worth investing your time to learn.
Answers of the form ‘X’, where ‘X’ is the name of a ‘real’ programming language, with variables and functions and flow of control and all of those things.
It was on this basis that I chose Emacs over vi. (A decision, I may say, that I have never regretted.)
The importance of macros was pretty clear to me because over my years of using VM, I had written dozens of macros for XEdit, the system editor, and the fact that I could write them in a well designed programming language (Rexx) was really important.
The funny thing is that having chosen Emacs over vi because it has a real programming language for macros, I then used Emacs for ten years or more before I ever actually used Lisp to write any macros. I decided that this was because all the macros I needed seemed to have been written by someone else already.
There is a page of useful links for XML users in Dutch at http://xml.beginthier.nl/.
Information for developers of Chinese XML systems can be found at the Chinese XML Now! website of Academia Sinica: http://www.ascc.net/xml/ This site includes a FAQ and test files.