Can Atom replace oXygen?
Virtually anyone working with XML files in the context of the Digital Humanities, and especially in the context of scholarly digital editing, knows the oXygen XML editor. It is mature and packed with useful features, and yet every new version brings even more features and improvements. In fact, it is an editing ecosystem rather than an editor. It entertains a close connection to the community that exists around the TEI and has, for instance, the TEI’s latest default schemas nicely integrated into the editor.
Of course, there is a price to pay for all of this. And that price is the fact that oXygen requires a paid licence for any extended use. Don’t get me wrong: producing a great software product and licencing it at a reasonable price to users who benefit greatly from its use is of course perfectly fine. And in many large-scale, long-term editing projects, the licence fee is certainly dwarfed by the staff costs the project involves, so no problem there either. (And if you are looking for an editor for your fully-funded, 12-year historical-critical edition project, read no further.) However, in some contexts, a licence fee is a problem: for instance, in small ad-hoc projects, in projects located in low-income countries, and in most teaching contexts, whether in the framework of a local curriculum or in workshop settings.
In teaching contexts, in particular, I don’t like to recommend and teach tools that students won’t be able to install on as many devices as they care to, and more importantly, tools that students won’t be able to continue using for free once they leave the university. This is one of the reasons why we recommend and teach Zotero rather than Citavi, when it comes to bibliographical reference managers, despite the fact that my university has a campus licence for Citavi. And this is the motivation that has driven me to find a suitable replacement for oXygen when dealing with XML-TEI files in the Digital Humanities. Another motivation has been that oXygen is actually rather more daunting, complex and feature-packed than what we need, whether in smaller editing projects or when teaching the fundamentals of XML markup.
Quite a few years ago, I used XML Copy Editor for teaching XML. It did a few things rather well and was decidedly minimalistic; a little too minimalistic, maybe. More recently, I moved on to the more versatile jEdit editor, a general-purpose text editor (useful to learn how to use anyways) that has a pretty convenient plugin ecosystem that also features several XML-related plugins, even XSL transformations. But in the last few months, I have turned to the Atom editor and found it to be the best solution yet, and the strongest contender with oXygen for small TEI projects and teaching contexts.
So, what does Atom offer? In a nutshell, Atom is a well-designed, general-purpose, free and open-source, cross-platform, customizable text and code editor that is particularly geared at programmers. It is developed by Github and therefore, features a very tight and convenient integration with Github repositories. As for XML editing, there are several plugins that provide most of the functionality you may need: pretty-printing, spell-check, autocomplete of your XML, schema-aware tool-tips, on-the-fly validation, and XSL transformations. Of course, it also lacks many things oXygen provides, so for example does not have things like an author view and does not come with any TEI schemas built in.
To unpack the nutshell a bit, so to speak, let’s have a closer look at the list of functionalities I mentioned above:
- Git/Github integration: This is provided by the core package ‘github-integration‘ that comes bundled with Atom. If you have Github repositories that you already cloned to your computer, you can simply add them to Atom as a ‘project folder’ and, once you have authenticated, you can pull, stage, commit and push right from your Atom editor window. Painless and easy. In practical terms, this means committing and pushing in smaller increments, which is better for your code or markup.
- Pretty-printing: This is provided by the plugin ‘atom-beautify‘. The plugin can do pretty-printing for a wide range of languages, including XML, and can be adjusted in quite a detailed manner in the settings.
- Spell-check: This functionality is provided by a core plugin, ‘spell-check‘, that ships with your default Atom install. All you need to do is install the right dictionary on your system and, to spell-check XML files, add the code “text.xml” to the list of ‘Grammars’ in the settings. You can set the language of the document you are currently checking in the plugin’s settings as well. (Setting this up could be a bit more straight-forward, to be honest.)
- Autocomplete: This functionality is provided by a plugin called ‘linter-autocomplete-jing‘. It suggests possible elements and attribute values based on a schema, and it shows tool-tips for your elements from the schema documentation (so for a given attribute value, for instance, it will show you the description of the meaning of that value).
- Validation: This is also done by the autocomplete package. It performs on-the-fly validation based on a schema that you indicate in the processing instructions, meaning that as soon as you type something in that does not follow your schema’s rules, it will highlight that line and describe the error you’ve made. This includes not just RelaxNG constraints, but also schematron rules!
To be honest, this leaves little to be desired for 99% of the needs we have when teaching XML and TEI to our students, and at least 95% of the needs I have come across when creating TEI-based text collections. Also, Atom is more accessible than oXygen. Finally, Atom is not just a well-rounded all-purpose text editor, but also a reasonably-powerful IDE for writing programming code. So you may come to Atom for its XML love and stay for its Python programming support!
Addendum, April 1st, 2020: The discussion on Twitter about this post has brought many more arguments to bear on the issue. Most importantly, another useful Atom plug-in was mentioned: wrap-in-tags, which does just that and is indeed very useful (sorry, can’t find the source). In addition: Another editor has been mentioned, VS Code (Kyonori Ngasaki) and its open source version VS Codium (Martin Sievers). The idea the oXygen has done a lot for the XML community and it is only fair to give something back through licence fees, especially in working life, has been mentioned (XMLArbyter). I have myself mentioned the likely benefit Github gets from Atom with its tight integration to… Github, and floated the idea of a free forever, “lite” version of oXygen as a possible response to free XML editor alternatives. Using all-purpose editors for editing XML has been mentioned as a way to wean people away from “mental XML-lock in” (Dirk Roorda). Thanks everyone for the good debate.
Addendum, November 24, 2021: Over the last year or so, I have also experimented with using Visual Studio Code / VS Codium as another alternative XML editor and am very pleased. Again, plugins are required for most XML-related tasks, but there is a solid choice of relevant plugins. First and foremost, I have been quite pleased with “Scholarly XML“, but there are more plugins. The editing experience is also very good, with Github integration out-of-the-box, for example. In addition, it is worth pointing out that the TEI plugin for jEDIT, developed by DARIAH-EU, seems to be very useful as well, though I have only given it a quick look so far. Happy editing!
Christof Schöch (2020): “Can Atom replace oXygen?”. The Dragonfly’s Gaze. Marseille: OpenEdition. URL: https://dragonfly.hypotheses.org/1127.
- Edit, March 28, 12h05: Frank Fischer notifies me that DARIAH is working on improving TEI support in jEdit, excellent news! See this announcement. [↩]
Thanks for this interesting article. I’d like to add an other point: Developing frameworks for oxygen is to some extend simple and fun. But if the needs of a editorial project grow, it gets more complicated and one has to write more and more oxygen-specific code. — It really would feel better and be better scientific practise (and IMO be a better use of public money), to invest development into free software, at least into open source software, instead of working on extensions for proprietary software.
I haven’t tried atom or vscode – and as a dedicated Emacs user and developer I definitely won’t :). But instead of propagating a specific editor, I’d like to point to a technology, that could turn virtually every editor into a decent XML-IDE: the Language Server Protocol (LSP). It let’s an editor connect to a so called language server, in this case and XML-LSP-Server (running locally on your computer). The editor sends the file being edited (or parts of it) to the LSP-Server which returns validation information, auto completion information, indenting information etc. There are LSP-Servers for virtually every language. In theory, every editor can be turned into an IDE for a specific language using this LSP-approach. It practice, the IDE-experience depends on the capability of the LSP-server.
In my opinion, DH-development of editing environments should be bundled into developing a decent XML-LSP-Server that would fit our communities needs. The LSP would serve as an abstraction layer and would provide pure functionality instead of functionality closely bundled with look and feel. You can then plug what ever you want.
If I had a wish for christmas, I’d like to see an XSLT-LSP-server.
Here’s a starting link to the LSP world: https://langserver.org/
Christian, SCDH Münster
You can also use https://yamlonline.com/ for the yaml validator as well as yaml converter to json,csv,xml,base64 also for beautify and minify YAML.
P.S. I’ve found this to be a helpful introduction https://andrewdunning.ca/getting-started-editing-tei-xml-atom
The Twitter discussion is interesting though as a non-German speaker I find it challenging to follow! And thanks for reminding us about this worthwhile product. I think the effort needed to produce a simple editor tailored to a particular user community/schema is roughly the same whatever tool you choose. As you say, the real significance of this is to demonstrate that putting your stuff into TEI XML makes it possible to work on your stuff with more than one tool. Aside from the moral arguments, one thing I like about oXygen is its reluctance to deal with non-XML encodings (apart from standard image formats), and I note your suggestion that Atom has an edge here. Or maybe not!
Interestingly, discussion takes place on Twitter, not here; see: https://twitter.com/christof77/status/1243856130624929792