Recently at my job I've had to spend a good portion of time working with a set of languages we created from scratch. It is interesting to think in terms of lexers and parsers, but I've hit the point where I wish I could just use XML and XSLT. Having a tree is powerful, especially when you have a language dedicated to recursively working within that tree.
The whole reason for writing the parser from scratch was for usability. The people that actually had to use the language have been better served with a more forgiving and simplified text format, so that's what was created. It is more difficult to program for, but our users have had a great deal of success, so the extra work has been worth it.
I was told that in the beginning XML was considered, but without an editor to ease the authoring pain, it wasn't practical for the users. It is interesting that the lack of a good editor was the stumbling block. From what understand, before XML was so widely adopted, advocates would suggest that editors will help ease the pain of getting all those angle brackets to disk. I could be getting my history incorrectly, but it doesn't refute the fact that the XML editor world is less than ideal.
There are some truly great XML editors out there. For example, if my hands weren't crippled with an addiction to Emacs, oXygen would be my tool of choice, hands down. It is a fantastic XML programmers editor. As good as oXygen is, it is not made for non-technical users. There have been attempts, especially in the land of publishing, that have proven to be fruitful. But, a generic XML editor that works reasonably well for non-technical users seems to be a myth.
One avenue that could be productive is a "XML by example" editor. Instead of requiring a complex schema, the editor would use a simple XML file as an example. Programmers are pretty good at writing software that creates XML, so this seems like a pretty reasonable requirement. XSLT or something simpler could be used to create a save or validation hook. This is where you could verify content types such as numbers or dates as well as links. Any system accepting the user created XML should already be prepared for malformed data in one way or another and writing an all encompassing output file makes for a very good test.
The larger question is whether or not it is too late for simple end user XML editors. Interest in XML has definitely been waning recently with technology like JSON becoming more popular. With that in mind, XML's strengths continue to be valuable, especially in traditional content management contexts. It is not surprising that traditional content is where a simple, generic, end user XML editor would be of the most value.
What do you think? Would a simple generic XML editor for end users be a valuable tool? What would it look like?
There have been some great comments, so thought I'd take a minute to make a few clarifications and respond.
First off, what I meant by a "generic editor" is really much closer to the description Evan offered below in the comments. I was thinking in terms of authoring content with XML as that is one area where I strongly believe XML excels. Paul Terrey mentions, Arbortext, XMetaL, Serna, etc., which were in fact the impetus for writing this article. George Bina (from oXygen) also points out there is oXygen XML Author, which seems to fall in a similar category as that of Arbortext or XMetaL.
Laurens van den Oever makes the point that a XML authoring editor should focus on providing valid output. Evan Lenz also suggests the importance of using XML Schema (or a DTD) when creating an editor. To some extent I agree, but the problem is that many groups that would benefit from using an XML based workflow, do not have the technical resources (read programmer) to setup a complex editor. Sure, they can hire a consultant, but that can be difficult and expensive to support.
One idea might be to allow traditional non-technical people make changes to their schema and add new formats. In this case, the solution is not only an authoring environment, but a schema building tool. Dimitre Novatchev mentions using Visual Studio for pulling a XSD from a XML file, which is a good low level strategy, but I'd imagine something more like Access would be required to help bridge the gap between low level details and end user usability. No matter what tools might be helpful, it is clear the problem is challenging.
Lastly, one reason I've been interested in a good XML authoring environment is for blogging. More specifically, blogging within the context of AtomPub. Having the ability to add and remove features via Atom Extensions seems like the perfect fit for a XML aware authoring tool. Likewise, taking oXygen XML Author as example, providing an Atom Framework that supports something like DITA or XHTML would allow for pretty powerful CMS integration. This sort of idea is nothing new. It is just finally much closer to reality.