Re: [email@example.com: Standard libxml-based processing scripts for DocBook?]
> Not using catalogs (or using them as an optional feature) is not good
> though; at KDE we are facing the following problems since we moved to
> XML DocBook:
> - how does a document find its DTD? The documents can be distributed
> separately from their DTD, so neither absolute paths nor relative paths
> work fine, unless autoconf or symlink hacks.
If you have LSB compilant xml docbook system installed, it is simple:
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
Public id is the "universal" part, but system id is LSB/linux path.
The disadvantage of this solution is that document becomes less "universal".
> - how does a DTD customization refer to the DTD files that it modifies?
> - how does a DTD provide hooks to customization files?
> - same for XSLT customization issues
Nevertheless, my general idea for solving dtd/stylesheet finding
problems would be as follows: using no pubid, only general URI as
system id, e.g "http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd"
and if the tools find the file already stored in "cache dir", e.g.
it would be taken from that dir, otherwise would be downloaded. No
catalog files... of course tools should be modified to use it.
But probably such issues was already discussed on related lists many
> The SGML LSB standard paved the way for such an absolute paths hierarchy
> by setting up a minimal set of rules in /usr/share/sgml. However, it
> also addresses catalog issues by a mechanism of centralized catalogs in
> /etc/sgml. I encourage you to read this document. So far the standard
I know the document. Few months ago I roughly switched SGML/XML
packages in my distro (PLD) to use it.
> does not state explicitely that XML setups should rely on absolute
IMHO this would be sufficient, for current needs (offline
> paths. When we wrote the standard we were hoping that catalogs would
> become a reality in the XML world, and we still do ;-).
Please, no! ;)
Rafał Kleger-Rudomin (firstname.lastname@example.org)