On Sun, 9 Mar 2003, Rafael Laboissiere wrote:
> This is not related to a parsing error or ill-formed XML, so the Perl
> modules are working fine for him. I looked at the position of the file and
> the script is choking at a "°" entity use. I traced down in my
> computer, and I discovered that this entity is defined in file
> which is included in DocBook through:
> In Debian, the former file is in package sgml-data (version 1.8) and the
> later in docbook-xml (version 4.2-6). Notice that sgml-data is a native
> package of Debian, which includes definitions for several different markup
> languages. Debian (as usual) has a very sophisticated dependency and
> organisational system that insures that things work correctly. In the case
> of SGML/XML, all the infrastructure is well implemented, such that catalogs
> are correctly found, for instance.
Thanks, Rafael, for that analysis. To expand that a bit further, sgml/xml
keeps track of important files through a hierarchy of catalog files. The
top-level catalog is normally located at /etc/sgml/catalog. At execution
time the catalog hierarchy is searched for the appropriate files
(identified by DOCTYPE statements in files that are directly input to the
application in question). That is why I made my recent commit so that the
plplotdoc.xml (rather than plplotdoc.xml.in) that is input for api2text.pl
had a well-defined DOCTYPE line.
That bug fix may be enough to solve the parsing problem on Joao's system.
However, if not, another possibility is the hierarchy of catalogs has been
screwed up on his system. The problem is that every different distribution
organizes this hierarchy differently and manages it with different tools.
For example, Debian uses update-catalog to manage these catalogs while
RedHat (and SuSe?) use xmlcatalog. (To see what is used on your system try
rpm -q --scripts docbook-dtds. That rpm is the appropriate one on RedHat,
but it may have a different name on SuSe.) If you try and install an
sgml/xml package from a different distribution than yours or from a tarball
or if the packager naively adapts another distribution's sgml/xml rpm
without paying attention to catalogs, you can have a screwed up catalog
hierarchy. Fortunately, the catalog hierarchy is easy to trace by hand (all
the files are human-readable) so problems are straightforward to diagnose
(with massive uses of locate, find, xargs, and grep).
In the near future, Rafael will be addressing the catalog issue for the
octave front-end to plplot by putting in configuration checks to test the
catalog hierarchy is working well enough to support api2txt.pl.
BTW, I don't agree with Rafael's claim that Debian has more sophisticated
tools than other distributions. (Although I am a Debian advocate like
Rafael, I try not to go too overboard with it....;-)) In my view what really
distinguishes Debian is the high quality assurance enforced by a rather
raucous group of users who will publically hound and embarass packagers (and
also submit helpful patches) until they get it right. Thus, way back for
Debian potato the sgml catalogs were fine while they were completely
screwed up for RH 6.2. I am hoping that will not be a problem for RH 7.3
and 8.0, but I hope to know a lot more about that later today.
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the Canadian Centre for Climate Modelling and
Analysis (www.cccma.bc.ec.gc.ca) and the PLplot scientific plotting software