Re: [klakier@pld.org.pl: Standard libxml-based processing scripts for DocBook?]
[I've only seen a couple of messages on this thread, so apologies if I
don't have exactly the right context.]
/ Eric Bischoff <e.bischoff@noos.fr> was heard to say:
| 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.
Some sort of cache is the only other (other than catalogs) practical
solution that I can think of to the problem of locating resources for
XML processing. But I'm not sure it's simpler or more natural. Or
easier to manage.
I know several people who think a cache is "the right answer". So I tried
it for a while. (I'm running wwwoffle now partly for that reason). It only
sortof works. I see some problems.
1. A generic cache doesn't really have enough knowledge about XML
processing to keep the right stuff around. I would want very different
expiration policies for files needed by XML processes than I do for
web pages.
2. A cache is "hidden" from the user. It's not easy to tell what's cached,
what isn't, what versions are cached, etc.
3. It only works for resources that can be located by http or ftp (or some
other cached protocol) the first time. It won't help with
<xsl:import href="urn:publicid:-:Norman+Walsh:Stylesheet+Website+V2.0:EN"/>
These problems could probably be solved with good cache management
tools, but I think a catalog is easier to explain and use (and
develop) than cache management tools. And it works on any platform;
right now wwwoffle doesn't work reliably on Windows I don't think.
| 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.
Absolutely.
| XML tools - but the second solution works out of the box with SGML, so we
| ensure backward compatibility and consistency in the SGML philosophy.
Note also that catalog support works "out of the box" (almost) with
some important tools now. Saxon has -X, -Y, and -Z options to provide
resolvers for external entities and URIs. Recent versions of Xalan
have -ENTITYRESOLVER and -URIRESOLVER options.
| 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
| :-(.
And most implementations of SAX parsers are broken (IMHO). They make
system identifiers absolute before asking the resolver to get them.
I think this is wrong, but it's awfully late to try to get it fixed.
Be seeing you,
norm
--
Norman Walsh <ndw@nwalsh.com> | 'Heartless Cynics,' the young men
http://nwalsh.com/ | shout, / Blind to the world of Fact
| without; / 'Silly Dreamers,' the old
| men grin / Deaf to the world of Purpose
| within.--W. H. Auden
Reply to: