Re: [klakier@pld.org.pl: Standard libxml-based processing scripts for DocBook?]
Le Jeudi 17 Mai 2001 14:37, Norman Walsh a écrit :
> [I've only seen a couple of messages on this thread, so apologies if I
> don't have exactly the right context.]
You got it pretty well ;-)
> 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.
Wow, I'll check this! This is excellent news :-). I hope libxml will support
them pretty soon too, this one is growing in importance every day.
I have a doubt about who should provide such an entity resolver, and how easy
it is to provide one, though. So far the only one I've seen was C++ code -
something out of the scope of a normal user.
Would it make sense to start thinking about providing entity resolvers for
the main tools, that would implement the catalogs mechanism, according to
you, Norm? So at least a document coming from package A could find easily the
DTD describing this document and coming from package B, without any
intervention from the user. It would be much cleaner than patches, and much
more maintainable too.
> | 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 can confirm. It is for example assumed in the source code for Xalan that
all sysids are absolute paths, and this one is a DOM parser as well as a SAX
parser. At least this one does no conversion to absolute paths - it simply
ignores that relative paths do exist :-/.
> I think this is wrong, but it's awfully late to try to get it fixed.
Hmm, this seems to close the door to relative path-based solutions.
--
É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: