On Saturday, December 01, 2001 9:57 AM
Ingo Mittendorf wrote:
> I tried to include an extensions DTD file in the internal DTD subset,
> containing these modifications, which, I thought, was supposed to
> any specifications made in the external DTD.
> This works fine with changes to attribute declarations, but when I
> slightly different declarations for the same element in both the basic
> the modifications DTDs, the editor/parser takes offence.
> I get an error message "Element XYZ already defined".
I'm interested to see you're persevering with the struggle to make
XML-Spy work with the TEI extension mechanism, but I suspect you're on
to a loser. XML Spy seems to get confused when, as part of the internal
subset, it has to expand a parameter entity which resolves to the name
of a DTD extension file. I think you'll find that if you replace this
parameter entity with the entity itself, i.e. place your modifications
directly into the internal subset, you won't get this error message. But
I accept that then you are lose much of the elegance and robustness of
the extensions mechanism. It's what I resort to, though, FWIW.
Lou Burnard recently remarked on the TEI-L that he'd be astonished if
XML-Spy couldn't handle the DTD extension syntax that TEI uses (which is
of course is perfectly legal XML) in the way that emacs-psgml does. But
I don't think supporting the TEI inclusions mechanism is very high up on
the priority list of the XML Spy developers. Their focus seems very much
on the moving target of schema support, and on the whole I don't quarrel
Maybe if more TEI encoders would commit to serious use of XML Spy, their
problems might carry more weight. But then XML-Spy is indeed an XML
editor, with no ability to handle full-blown SGML (a problem for some
TEI folk), it runs only on Windows (an even bigger problem for others)
and handles utf-8 encoding transparently and faultlessly, thus
threatening to part people from their beloved character entities and
numeric references. And to be honest, provided people don't insist on
their DTD extension methods going entirely by the TEI book, it's an
excellent editor for TEI encoding purposes, especially now that the
Document Editor features on 4.x mean it can be used by people who want
something approaching a WYSIWIG interface.
> Another thing that puzzled me was that the editor/parser takes offence
> the element declaration in the *internal* DTD (it opens the
> file and highlights the element in question), when, at least, I would
> expected that it would take offence at the *external* element
> (which is read after the internal DTD, isn't it).
Well, it's a characteristic of parsers of all kinds that they are seldom
good at reporting precisely where their objections arise, probably
because of the inherently recursive nature of their code (by the time
they've backed off to the error-reporting level, they've long since
popped the offending spot off their stack) Obviously to raise this (as
it happens, incorrect) objection at all, the parser has to be comparing
an entry in the internal subset with one it has just found in the
external DTD. Not all that suprising then, that it points the finger at
the corresponding part of the internal subset.
Michael Beddow http://www.mbeddow.net/
XML and the Humanities: http://xml.lexilog.org.uk/
The Anglo-Norman Dictionary http://anglo-norman.net/