I also was once confronted with the unavailability of a free (or at
least affordable) XML editor for students. That was more than ten years
ago. I am not up-to-date of the options today, but in 2003/2004 all
open-source or free XML editors where either totally unreliable or
extensions of general purpose editors with a too steep learning curve.
Since I already had written an XML parser for Delphi, I decided to write
my own textual XML editor. I used two other 3rd-party components, of
which only a textual-editor component was really essential. I first made
it completely open source and named it "Open XML Editor". In its
high-days it had more than 100,000 downloads a year. Later I decided to
implement some advanced features that require to purchase an activation
key as a test-balloon. As the adjective "Open" was no long appropriate,
I renamed it to "Essential XML Editor" (meaning that it includes only an
essential feature set).
I still use the editor today to for teaching courses on XML and TEI at
the beginner level, which focuses on XML, DTD, TEI and a little XSLT. I
would like to present here my thoughts on the "Basic required features"
as outlined in
primarily from the perspective of a software developer with a business
> 1.1. multiplatform
Is this really so important? Most students work only on Windows and even
those how use Linux or Apple should have access to a Windows computer.
Providing an editor for three different platforms would substantially
increase the development costs, because a substantial effort for
developing an editor needs to go into the GUI. Of course one could
compromise and for example develop for the JAVA virtual machine only.
But this would not result in an application that feels native to the
uninitiated (in contrast to requirement 1.6: "easy to use"). Developing
a browser application instead would lead to a lot of other difficulties,
such as working around ever changing browser incompatibilities or how to
manage 3rd-party plug-ins for such things as XSLT processing or Schema
validation. -- Therefore I think for teaching beginners an application
for Windows is the minimal requirement and every platform supported
beyond is nice to have but not essential.
> 1.2. validation with Relax NG based on the xml-model PI in the document
If the editor should only call an external validator and present its
output in a message window, it can be achieved easily (this feature was
the aforementioned test-balloon for the advanced version of my editor).
If interaction between the validator and the editor is desired such as
the ability to interactively correct the source document based on the
validator's output this can be a very demanding feature.
> 1.3. continuous validation
This can become very tricky to implement. Usually one needs to implement
this in a separate thread, which might be hard to debug. A lot of
special cases need to be taken into account, since when editing an XML
document in a text editor it will most of time be invalid. Also from a
teaching perspective it is not really necessary to continuously validate
a document. Usually the student has an idea what she wants to achieve,
when she thinks that everything is al-right, she can click on a
"Validate" button, and on encountering a violation of a validation
constraint can repeat this process.
> 1.4. contextual suggestions (following the schema)
This is related to 1.2: If the validator is external, this might be
impossible to achieve. If this feature is mandatory, one needs either a
3rd-party validator that exposes a suitable API or one needs to write
the validator from scratch. And even if such a validator is available,
it is not trivial what the suggestions should look like. -- In my case,
I had my own DTD-validator available. If my test-balloon had been a
success this might have been one of the next features to implement, but
even if an element model gets a little bit complex (such as nested AND
and OR brackets), one may give not much automatic guidance, because what
makes sense at a certain place might depend not only on the elements
preceding, but primarily on what is about to follow.
I observed a similar problem regarding well-formedness errors: If we
have a document like
where is the right place to insert the missing </foo> or need we remove
one of the opening <foo>s (which one?)? We cannot identify a single
location for fixing the error. My parser discovers the well-formedness
violation when it reaches the final </doc> and discovers that it has
still the first opening <foo> in its list of open element tags and stops
there with an error message about an unclosed <foo> start-tag. But the
place to fix the error is usually somewhere else. Providing better
guidance in such a case is not simple.
> 1.5. XSLT 2 transformation (Saxon HE? that would offer XQuery as well)
This raises the same issues as 1.2. In my editor, Saxon can be installed
as a plug-in, so that its output can be automatically loaded as a new
XML document. But it is not possible to call it interactively for
example to debug an XSLT script and to see how the output document is
> 1.6. easy to use
This points really needs clarification. As mentioned before it stands in
a certain contrast to 1.1. It depends on the pre-knowledge of the
intended users. It depends on the numbers of features required.
> 1.7. free for students
Now we need to talk about economics: How long does it take to create
such an editor from scratch and set-up the Website to promote it? I
would say somewhere between 3 and 12 month depending on the details of
the feature set (or more like 24 month if we need to write our own
validator) by a senior software developer (10+ years of experience in
the field). This means between 450 and 1,800 hours of work. I doubt that
trusting the work to a cheaper beginning programmer would be a better
strategy since it is quite demanding, because it involves a lot of
different technologies and benefits from experiences with other larger
The income for a senior software developer here in Germany is in the
same league as, or perhaps even somewhat above, the salary of a
professor. A search for the going freelancer rates here for a software
developer with 10+ years of experience in one of the major programming
languages will yield rates of about 70 Euro per hour. *If* the above
estimate for the time requirement was more or less correct, we would
need to invest 31,000 to 126,000 Euro into the project. Note that this
would be the price for a sponsor who is willing to pay market rates for
such a software right out of his pocket. If we need to place the
software on the market, we would encounter additional costs. First we
need to add interest rates to our time investment, because we are not
going to sell all the copies on the first day. Then we run the risk that
there is no sufficient market for our product, that we need to provide a
certain amount of unpaid support, have other market transfer costs, etc.
To compensate for this we need to aim for a market that has at least
double the value of our estimated time investment, ie. 62,000 to 252,000
Euro. Is the Digital Humanities market big enough for that? How much
would your institution pay for such an editor, in addition to the
professional editors? And even if we make the editor not completely free
for the students, the market seems too small to me: If a student is to
pay 10 Euros (as is the price for my test-balloon) we would need to sell
6,200 to 25,200 copies in a reasonable amount of time.
I would not give you the numbers from my test-balloon, but they indicate
that there does not exist a market for a paid Essential XML Editor.
People either play around with the free tools or have serious work to do
where the price for Oxygen or XML Spy is no important cost factor.
Of course the situation for a company with an established XML editor to
offer a downsized version is different. But they also have costs for
creating such a version in the first place and for maintaining it to
keep it in sync with their updates. I would reckon that even for them
the value of the market must not be much lower as the estimates
presented above, probably with better values at the high end of the
estimate, because the fix costs of the alternatives (eg. tests) should
> 1.8. syntax highlighting for XML (that naturally includes XSLT)
This should be easy. In my case the 3rd-party text-editor component
already included syntax highlighting. So I had only to write a few lines
of code to adjust it to my needs. However, using a 3rd-party text-editor
component is the most problematic part of the whole application. At the
time of implementation it was the only reasonable open-source component
of its kind for Delphi (and I think it still is), but was not of very
high quality. In this case it did not help that it was open-source,
because the whole code base was not in a good shape (unstructured,
undocumented, etc.). So I had to decide whether it is worth the effort
to fix a certain bug or just leave it.
Some final remarks: The sources for the latest Open XML Editor version
1.6.2. are still available for download. All its packages (the Delphi
term for its modules) are dual-lincensed under MPL 1.1 and either LGPL
or GPL (depending on the package). So anybody with a certain knowledge
of Delphi, who feels more optimistic about the market for such an editor
than I did, need not start from scratch.