Re: [klakier@pld.org.pl: Standard libxml-based processing scripts for DocBook?]
Sorry for crossposting - I know it's a very bad habit of mine ;-)
Le Mercredi 16 Mai 2001 12:48, Rafał Kleger-Rudomin a écrit :
> > - 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"
> "file:///usr/share/sgml/docbook/xml-dtd-4.1.2/docbookx.dtd">
>
> Public id is
> the "universal" part, but system id is LSB/linux path. The disadvantage of
> this solution is that document becomes less "universal".
Exactly. But can you guess the problems we face at KDE when we distribute
documentation? The target system could very well be non-LSB, and we still
have to guess an absolute path. We could do it via autoconf, though :-/.
> > - 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
>
> as above
... which also supposes your system is following the LSB recommandations (I'm
happy now that at that time we didn't work only at setting up a centralized
catalogs mechanism, but also at defining absolute paths; it was redundant
with SGML but it is not with XML).
> 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";
We also already thought about this solution at KDE. But what about if you
have no Internet connexion ;-) ? Are laptops in planes condemned not to be
able to render documentation ;-) ?
> 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?
> it would be taken from that dir, otherwise would be downloaded. No
> catalog files... of course tools should be modified to use it.
This is the point ;-). I would even prefer XML tools to be modified to use
the existing mechanism: the catalogs ;-). I know Norm is working on this
currently.
> But probably such issues was already discussed on related lists many
> times...
They were, but it's nice that this gets reformulated on some LSB list.
> I know the document. Few months ago I roughly switched SGML/XML
> packages in my distro (PLD) to use it.
You are not the only one :-). Most distributions already switched to the new
absolute paths.
> > 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! ;)
You seem to have bad experiences with catalogs ;-). Believe me, if used in a
structured way (with some starting point in /etc/sgml), they become a very
great tool, allowing you to switch from versions for your documents easily
for example. We thought absolute paths as a fallback - and we are happy to
have it now that we discovered that many XML tools don't honour the FPIs.
--
É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: