Bug 40812 - dbcent.mod patch yields a broken dbcent.mod
Summary: dbcent.mod patch yields a broken dbcent.mod
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: docbook-dtd41-xml
Version: 7.0
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Tim Waugh
QA Contact:
Depends On:
Blocks: 37192
TreeView+ depends on / blocked
Reported: 2001-05-16 02:41 UTC by Gregory Leblanc
Modified: 2008-05-01 15:38 UTC (History)
0 users

Clone Of:
Last Closed: 2001-07-17 23:17:13 UTC

Attachments (Terms of Use)

Description Gregory Leblanc 2001-05-16 02:41:57 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-22 i586; en-US; 0.8.1)

Description of problem:
I've been looking into making some DocBook XML stuff work on Red Hat Linux
7.0+ (I've got the rawhide DocBook stuff installed).  I'm currently using
libxml2-2.3.8 and libxslt-0.9.0, both compiled locally.  I've also unzipped
Norm's XSL stylesheets (1.29) into /usr/share/sgml/docbook/xsl-stylesheets/

How reproducible:

Steps to Reproduce:
1. run libxslt
2.observe output

Actual Results:  /usr/share/sgml/docbook/xml-dtd-4.1/dbcentx.mod:53: error:
Space required after the Public Identifier
ISOamsa PUBLIC "ISO 8879:1986//ENTITIES Added Math Symbols: Arrow Relations//EN
/usr/share/sgml/docbook/xml-dtd-4.1/dbcentx.mod:53: error: SystemLiteral "
or ' expected
ISOamsa PUBLIC "ISO 8879:1986//ENTITIES Added Math Symbols: Arrow Relations//EN

Expected Results:  Should use xsltproc to transform said XML document into HTML

Additional info:

There are actually a slew of errors similar to the one above, all of which
corespond to one of the lines that was changed in the dbcent.mod, or some
entity which can't be found because of those changes.  I took a look at the
way that things get set up, and I see that make install isn't installing
the XML versions of these entity files.  I'm not sure if the XML entities
are different from the SGML ones, so I can't say if that's the right
I'm pretty convinced that I don't understand how dbcent.mod should be
pointing to the entities, so I'm giving up on providing a fix, at least for

Comment 1 Gregory Leblanc 2001-05-20 20:17:03 UTC
I've been messing around with this today, and I think I've figured out the
problem (although no solution, yet).  Since DocBook XML is XML (well, duh), it
has a dbcentx.mod, which is different from the one in the DocBook SGML package.
 the differences show up in the ENTITY declarations.  SGML allows for a simple
mapping of entities to PUBLIC identifier, while XML requires both a PUBLIC -and-
a SYSTEM identifier.  
I'm not sure if it is kosher to share entities between SGML and XML (they're
currently included in the sgml-common package).  If they can't be shared, then
the creation of an xml-common package will be necessary.  If they -can- be
shared, then we need to figure out a way to determine where the sgml-common
package has put the entities, so that we can put the SYSTEM identifier in properly.
So, is that clear as mud, and which guesses am I completely wrong about?

Comment 2 Tim Waugh 2001-05-21 08:39:49 UTC
Yes, we need an xml-common package I think.

Comment 3 Gregory Leblanc 2001-05-21 18:51:48 UTC
I just tried using the entities from the sgml-common package with my home-brew
docbook-dtd412-xml package, and they don't work.  :-(  I'll try to look at an
xml-common package today.  Things should end up installed in
/usr/share/sgml/xml-iso-entities-8879.1986  if I'm not mistaken.
I'm stuck trying to figure out what the patch to dbcentx.mod should look like,
but maybe it will be clear after I have an xml-common package.

Comment 4 Daniel Veillard 2001-07-17 23:17:09 UTC
The right solution is to switch to XML catalogs for XML resources
at some point:

I will try to implement XML Catalogs into libxml before the next
Red Hat release, then we will have a standardized and scalable
solution for XML cataloging needs that can be installed in 
/etc/xml/catalog and /usr/share/xml/ 


Comment 5 Tim Waugh 2001-10-19 12:36:49 UTC

Note You need to log in before you can comment on or make changes to this bug.