On Thursday February 27
Brad Scott wrote:
> List members might be interested to know that Altova have just released
> an XML editor AUTHENTIC 5 for free; it is a cut-down version of XMLSpy,
> and is interesting in that it has some degree of TEI support. In my
> (very) quick trial with it just now I could only get the TEILite part to
> work, but that could well have been me. Looks like it will probably only
> have a quite narrow range of uses for the moment.
> See http://www.altova.com/download_authentic.html
XML-Spy and TEI has been the subject of a fair amount of discussion, on and
off-list in the past. Since more people may now want to try the free
version, it might be useful to summarise some of the issues that have been
One caveat: the way the product licensing works means that I personally
can't replicate an installation of the free version on my W32 machine, since
it already has a licence key for XML-Spy professional in place. That
shouldn't really affect anything, though.
1) XML-Spy works fine with TEI-LITE or any compiled DTD from the Pizza
Baker. It will NOT work with customisations that rely on local
parameterisation processing on the fly. Over the past couple of years this
has been the subject of exchanges between TEI users with Spy
licences and Altnova support. The latter generally claim that there is
something wrong (SGML-only) about the TEI parameterisation mechanism. That
is probably incorrect, but as far as I'm concerned life's too short, and
since the Pizza Baker is open all hours, I gave up on that one.
2) Unicode support.
First point: forget Windows 9x/ME (such amenesia is in any case profoundly
and universally to be wished). Spy may appear to be sort-of working
with utf-8 or utf-16 encodings under 9x/ME, but believe me, it soon ends in
tears. So run it under NT4, W2K or XP only unless you never need go beyond
Second point, even under NT etc there are unsquashed bugs in Spy's handling
of utf-8 encoding, specifically where clipboard operations are concerned
(and not everyone may realise that this covers not just cut-and-paste but
also drag and drop). The symptom is that you cut a utf-8 character which
does not have an ISO-8859-n codepoint from one Window in Spy and paste it
into another. The on-screen rendering of the pasted character seems fine
(provided you have set your text font to one that has the requisite glyph)
but when you save and reload the file, the pasted character has been
corrupted. More insidiously, if you are writing a style sheet, and
paste/drag a character from a document instance into an XSLT expression you
want to match that character, you will find that the expression looks fine
on screen, but doesn't in fact match when the XSLT runs (because of the
hidden corruption). This has in the past cost me a lot of my pretty scarce
On the plus side, you can, however, enter whatever characters you like
directly from the keyboard, or via the numeric keypad or an IME and they
will be stored and processed correctly, as well as correctly displayed. The
same applies if you load files prepared in other utf-8-savvy applications
into Spy and save them again. Provided nothing goes through the clipboard,
all is well.
Rider to the second point. This corruption occurs when your default system
locale is one that causes NT to assume one of the ISO-8859-n family as your
default document encoding. You can work around the problem by changing your
default system locale (NOT the user input locale, as some NT support people
will advise you to do, since that change doesn't dig deep enough into the
innards to effect clipboard handling) to a locale that assumes "wide"
characters in your default documents. This is a vital point for those who
need to know it, and it is one that virtually no Windows support staff seem
to understand. But it is too technical to explore here. I will gladly say
more off-list to anyone who cares to mail me.