Bug 37192 - Troubles with dbcentx.mod
Troubles with dbcentx.mod
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: docbook-dtd41-xml (Show other bugs)
7.1
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Tim Waugh
:
Depends On: 40812
Blocks:
  Show dependency treegraph
 
Reported: 2001-04-23 08:19 EDT by Daniel Veillard
Modified: 2008-05-01 11:38 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-10-19 08:36:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Daniel Veillard 2001-04-23 08:19:15 EDT
[I posted this first to docbook@lists.oasis-open.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
Comment 1 Daniel Veillard 2001-05-02 17:33:15 EDT
I think it's fixed when upgrading to DocBook 4.1.2

Daniel
Comment 2 Tim Waugh 2001-05-02 17:35:05 EDT
Yes.  I guess it needs a new package then, docbook-dtd412-xml.
Comment 3 Daniel Veillard 2001-05-21 04:08:25 EDT
Can we get a docbook-dtd412-xml or an updated docbook-dtd41-xml package in
RawHide ? this would help,

Daniel
Comment 4 Tim Waugh 2001-05-21 04:41:52 EDT
I'll go for a 4.1.2 package rather than updating 4.1 I think.
Comment 5 Tim Waugh 2001-05-22 05:40:31 EDT
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.
Comment 6 Tim Waugh 2001-05-22 05:41:15 EDT
*** Bug 40812 has been marked as a duplicate of this bug. ***
Comment 7 Daniel Veillard 2001-05-22 06:17:56 EDT
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
Comment 8 Gregory Leblanc 2001-05-22 10:05:05 EDT
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.  
Comment 9 Daniel Veillard 2001-05-22 10:28:34 EDT
> 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
Comment 10 Tim Waugh 2001-10-19 08:38:33 EDT
This is all sorted out in the rawhide packages.

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