Bug 37192
Summary: | Troubles with dbcentx.mod | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Daniel Veillard <veillard> |
Component: | docbook-dtd41-xml | Assignee: | Tim Waugh <twaugh> |
Status: | CLOSED RAWHIDE | QA Contact: | |
Severity: | high | Docs Contact: | |
Priority: | medium | ||
Version: | 7.1 | CC: | dcm, gleblanc, msw |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2001-10-19 12:36:58 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 40812 | ||
Bug Blocks: |
Description
Daniel Veillard
2001-04-23 12:19:15 UTC
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. |