On Fri, 2005-04-15 at 22:18, Paul Tremblay wrote:
> On Fri, Apr 15, 2005 at 09:20:37AM -0400, Alastair Dunning wrote:
> > From: Alastair Dunning <[log in to unmask]>
> > To: [log in to unmask]
> > Date: Fri, 15 Apr 2005 09:20:37 -0400
> > Subject: Choosing an XML editor
> > The article is based on a study by Thijs van den Broek, Benchmarking XML
> > editors, undertaken in 2004. The evaluation includes results of the survey
> > van den Broek undertook via the TEI website.
> Very useful article. What I really want in an XML editor is WYSIWYG.
> This is the only type of editor that allows me to forget about
> obtrusive technical matters when I am writing. I have not been able to
> find anything that suits my needs that is open source or that doesn't
> cost a small fortune.
epcEdit (www.epcedit.com) is reasonably priced, but it doesn't yet have
stylesheet controls to allow formatting to be affected by attribute
values. Otherwise it's quite good, and it's multiplatform.
My problem in using WYSIAYFWG editors is that it's hard to tell where
you are, especially if they use OS-manufacturer-specific libraries that
do silly things with mouse controls, such as automatically include the
trailing space on a word when double-clicked -- so you end up with
idiocies like <emph>this </emph> (have you ever seen an italic space?)
Cursor positioning is hard to see when there's nothing on-screen to
guide you. I've lost count of the number of times I've done things like
going back to a list item to add a word or two to mixed content ending
in an element, and finding I can't get my cursor in between the end-tag
of the final element of the content and the end-tag of the item element
without having to turn tag display on first.
(As I said, I'm doing research into editor and author behaviour, so the
report above is extremely welcome and a very useful piece of work).
> What I have ended up doing is writing in a type of "smart text" and
> using a python script to convert it to XML. For example, if I write
> *some text*, the python script converts it to <emp> some text</emp>. I
> can then use an XSLT stylesheet to convert the XML to a more suitable
> form, like TEI. This method is a complete hack, but it does allow me
> to create documents in a sane manner. For example, I am writing a
> document on how to use ConTeXt to convert XML to PDF. I wrote the
> document in my smart text format and then converted it to TEI.
> Occasionally I open up the TEI to see what is going on, and the TEI
> document is so cluttered, I couldn't possibly imagine using it by
> itself for documents.
Actually, I'd worry more about using TEI for authoring computer
documentation. I've found it easier to use DocBook for that.
> I also think a very powerful tagless editor would help in converting
> Word users to use XML. I have recently converted my girlfriend to the
> power of using CVS on her Mac OSX. She has to use the terminal, and
> for the first time she sees that the power and use of something that
> is not MS Office. She also knows that a structured document is far
> superior to a WYSIWYG document. It wouldn't be too difficult to get
> her to actually write in XML, but the main barrier is a good tagless
> editor. Right now she uses Word, and I use a very sophisticated script
> (http://rtf2xml.sourceforge.net/) I wrote to convert the MS RTF to
> XML, which I then convert to TEI. Yes, definitely another hack--but it
This is one of the underlying currents to my present work: there simply
are NO document-centric XML editors around. The WYSIAYFWG layer is just
pasted over the tags-on editor for marketing purposes. It is possible to
thrash EPIC or XMetaL to within a millimeter of their lives by using
scripts and stylesheets to get close to what is needed, but there is a
performance hit, and the result is expensive.
> I say all this just to explain the work-arounds I have employed to
> create a decent way to create XML documents.
Being an old IT lag, I just use Emacs for everything anyway :-)
> So I read the article with interest and immediately tried to find
> editors that offered WYSISYG. Epic seems like it fits into this
> category, but it is prohibitively expensive. Xmetal also seemed very
> nice, but also very expensive. Open Office is also a possibility, but
> you can only use it for simple documents.
Right on all three counts, except that OOo is moving rapidly towards
implementing arbitrary XML. Word 11 already does this, but it is
restricted to W3C Schemas. Have a look at WordPerfect XML Editor,
> There is another editor called vex, which also offers WYSIWYG editing.
> It also offers a tree view of a document. It is an open source project
> available on sourceforge. However, it is only in the alpha version,
> and worse, it uses Java. The few times I downloaded and tested it, it
> crashed, but even worse, it was simply too slow for me to ever
> consider using it. The article's use of the term "performance problem"
> for Java editors is understatement. Java often means the editor is
> simply unusable, as in it takes 20 seconds to move the cursor a few
> lines if you have a large document. (The exception is jedit, which I
> have found works pretty decently on most documents.)
My CS colleagues tell me that Java has been "proved" to be just as fast
as C or C++. The rest of the world seems to believe otherwise. It's the
current vogue, so we're stuck with it until we vote with our feet.
(Any language that starts by declaring its main routine to be void *has*
to be semantically brain-dead anyway :-)
> I use vim as my editor, and it was interesting to see how poorly vim
> did in this article. This doesn't surprise me, since I've found vim
> unsatisfactorily. It's a great editor, but poor XML editor.
I don't think anyone would disagree with that, although I find the
concept of a twin-mode editor (where you have to press something before
you can start typing, and press another key afterwards to stop typing
before you can use editor controls) to be a holdover from the 1960s.
But that's just my prejudices showing :-)