Re: [klakier@pld.org.pl: Standard libxml-based processing scripts for DocBook?]
Le Jeudi 17 Mai 2001 02:44, Rafał Kleger-Rudomin a écrit :
> > > and if the tools find the file already stored in "cache dir", e.g.
> > > /var/cache/xml/http:/www.oasis-open.org/docbook/xml/4.0/docbookx.dtd
> >
> > This is a great idea - but do we know any tools that currently implement
> > this? It's the same as developping tools that have their own entity
> > resolvers. It works, but what about using tools out-of-the-box?
>
> Nope, so far. Nevertheless such an approach is simple and much more
> natural than catalogs.
I'm not sure. Having an indirection system that says "this document uses XML
docbook version 4.1.2" is both intuitive, platform-independant and powerful.
This is basically what a FPI does. To me, having only optional FPI support in
XML tools is a major step backwards.
> (...) I'm just wondering why
> such simple and promising idea has not been proposed as a standard for XML
> tools to replace catalogs?
>
> (...) Then, add 'cached' dtds:
> mkdir -p /usr/share/xmlcache/http:/www.docbook.org/xml/4.1.2/
> cp -a /usr/share/sgml/docbook/xml-dtd-4.1.2/*
> /usr/share/xmlcache/http:/www.docbook.org/xml/4.1.2/
This needs to be done by manual user intervention or post-install scripts. So
it's not very different from what we have when we require people to edit
catalogs. Compare the two following command lines:
cp -a /usr/share/sgml/docbook/xml-dtd-4.1.2/*
/usr/share/xmlcache/http:/www.docbook.org/xml/4.1.2/
and
echo "CATALOG /usr/share/sgml/docbook/xml-dtd-4.1.2/catalog" >>
/etc/sgml/xml-docbook-4.1.2
aren't they basically equivalent?
The second method just provides a pointer while the first one duplicates all
data - which can bloat your hard disk.
Both solutions provide the same functionality and both require a patch to the
XML tools - but the second solution works out of the box with SGML, so we
ensure backward compatibility and consistency in the SGML philosophy.
One could imagine an intermediary solution in between the cache and the
catalogs methods, based on the relative paths. If a document mentions a
system identificator "docbookx", we could have a symlink, for example in
/etc/sgml/xml-sysids/, that allows to find where the "docbookx" file really
lies. It would allow to use SYSIDs like the cache solution, avoid bloating
the hard disk like the catalogs solution, but again need a patch to the tools
:-(.
> I know that catalogs are convenient for users - if they are already set up
> properly. But I really dislike them as maintainer of XML/SGML rpm packages.
> Using centralized catalogs in the way LSB suggests is simpler than
> it had been done earlier, but is still too complicated
> (big %post scripts, 3 catalog files needed to find one dtd file,
> (de)registration procedure requires some parsing, etc)
This is very true. Centralized catalogs are very simple to use when you are
able to modify manually a configuration file in /etc/sgml. All you have to do
is list all the SGML/XML components that you need to perform a given task.
Seting the right entries from a %post script is much more tricky, yes. This
is essentially due to the fact that we don't just put everything in one big
super-catalog (HTML mixed up with docbook together with TEI and OMF and CALS
and I don't know what else). We did this choice to increase performance and
avoid namespace conflicts. A "super-catalog" /etc/sgml/catalog is there, but
only as a fallback.
--
Éric Bischoff - Documentation and Localization
Caldera (Deutschland) GmbH - Linux for eBusiness
Tel: +49 9131 7192 300 - Fax: +49 9131 7192 399
http://www.caldera.de/
Reply to: