[I posted this first to docbook.org 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 Relations//EN 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"> <![%ISOamsa.module;[ <!ENTITY % ISOamsa PUBLIC "ISO 8879:1986//ENTITIES Added Math Symbols: Arrow Relations//EN"> %ISOamsa; <!--end of ISOamsa.module-->]]> [...] --------------------- But the XML spec only allows PUBLIC ids if followed by a SYSTEM one: http://www.w3.org/TR/REC-xml#sec-entity-decl [72] PEDecl ::= '<!ENTITY' S '%' S Name S PEDef S? '>' [74] PEDef ::= EntityValue | ExternalID [75] 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. thanks, Daniel
I think it's fixed when upgrading to DocBook 4.1.2 Daniel
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, Daniel
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 lists /usr/share/sgml/sgml-iso-entities-8879.1986/ISOamsa.ent 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. Daniel
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 error ! 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* ! Daniel
This is all sorted out in the rawhide packages.