[I posted this first to email@example.com but since I didn't
got an answer let's report it directly in Red Hat' BugZilla ]
Found that Red Hat 7.1 ships a docbook XML package with the 4.1.2
Dtds, this looks great so I try it ... and my parser chokes on it.
orchis:~/XML -> ./xmllint --valid --noent --noout panel.xml
file:///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
Looking at the file it says:
<!-- DocBook XML character entities module V4.1 ...........................
$Id: dbcentx.mod,v 1.7 2000/06/19 14:40:17 nwalsh Exp $
<!ENTITY % ISOamsa.module "INCLUDE">
<!ENTITY % ISOamsa PUBLIC "ISO 8879:1986//ENTITIES Added Math Symbols:
<!--end of ISOamsa.module-->]]>
But the XML spec only allows PUBLIC ids if followed by a SYSTEM one:
 PEDecl ::= '<!ENTITY' S '%' S Name S PEDef S? '>'
 PEDef ::= EntityValue | ExternalID
 ExternalID ::= 'SYSTEM' S SystemLiteral
| 'PUBLIC' S PubidLiteral S SystemLiteral
So the question is:
- did Red Hat shipped a wrong (or old/buggy) version ?
- is this file actually need to be fixed in the DocBook XML distrib ?
- or did I missed something ?
All I can say is that this bug doesn't seems to show up with the 4.1.2
downloaded from Norm's site.
I think it's fixed when upgrading to DocBook 4.1.2
Yes. I guess it needs a new package then, docbook-dtd412-xml.
Can we get a docbook-dtd412-xml or an updated docbook-dtd41-xml package in
RawHide ? this would help,
I'll go for a 4.1.2 package rather than updating 4.1 I think.
The problem is the dbcentx _patch_ in the src rpm, which changes valid
ENTITY declarations into invalid ones, deleting //XML as it goes. This is
from Eric Bischoff's packages, and I guess it just needs a system identifier
adding to it.
Daniel, is it possible/advisable to share the entities in sgml-common between
SGML and XML? If not, we need an xml-common.
*** Bug 40812 has been marked as a duplicate of this bug. ***
We cannot share in general the entity definitions with SGML
I picked the first example:
rpm -qil sgml-common
it's first declaration is
<!ENTITY cularr SDATA "[cularr]"--/curvearrowleft A: left curved arrow -->
And this is not an acceptable ENTITY declaration for XML
I really suggest to switch to xml-common, based on the entities declarations
from DocBook XML 4.1.2, use /usr/share/xml and /etc/xml/catalog .
We can reuse a subset of the SGML open catalog for XML without problem
(expecially the PUBLIC and CATALOG declarations allowing to build a
base of local files for PUBLIC resources). Until we have a clear new
standard (like RDDL) for XML catalogs, I suggest to reuse the SGML one
and the associated tools.
If we're going to be reusing the SGML tools, I don't understand why we need
/usr/share/xml and /etc/xml. We can just reuse /usr/share/sgml, and /etc/xml.
/usr/share/sgml is used for storing the DTDs and entity sets, and the file
naming conventions from the LSB specify how to name things to avoid overlap.
Since you've proposed that we use the SGML Open Catalog Format for the XML
catalogs, they'll be the same format as the SGML CATALOGs in /etc/sgml. Since
we don't have any clear format for XML catalogs, it seems that we could just
keep all of the catalogs together.
> If we're going to be reusing the SGML tools, I don't understand
> why we need /usr/share/xml and /etc/xml.
Because XML is a *subset* of SGML. Basically trusting that anything
stored in the SGML subtree could be processed by XML tools is a design
Since we are now deploying XML only tools the LSB convention is *clearly*
improper. We can reuse the naming convention but in separate subtrees.
I promise an endless suite of "but this fails" on the user side, as we are
starting to experience. And there been only a few people who tried to
use this framework with XML tools and it's just breaking all over the place.
> Since you've proposed that we use the SGML Open Catalog Format for the XML
> catalogs, they'll be the same format as the SGML CATALOGs in /etc/sgml.
> Since we don't have any clear format for XML catalogs, it seems that we
> could just keep all of the catalogs together.
No this is precisely the assumption people have done and which is clearly
broken !!! Independantly of the catalog format *THE* point we need to insure
is that IT WON'T BREAK. And as long as we will be pointing XML tools into
a set of SGML resources *IT WILL BREAK* !
This is all sorted out in the rawhide packages.