Re: [docbook-apps] DocBook XSL, DocBook 5, and Xalan

["Michael(tm) Smith" <smith@sideshowbarker.net>]

Elliotte Harold <elharo@metalab.unc.edu> writes:

> Michael(tm) Smith wrote:
> 
> >It recognizes "exsl:nodeSet" but not the correct exsl:node-set.
> >
> >  --Mike
> 
> That would explain it. Hmm, I wonder what's easier:
> 
> A) Fixing Xalan
> B) Hacking all the stylesheets so they work around this bug
> C) Switching to Saxon
> D) Consuming enough alcohol that this no longer matters.
> 
> I suspect C, but D's feeling really tempting right now. :-)

Based on a fair amount of first-hand experience, I can say with
some confidence that option D produces the most satisfying
results, at least in the short term. It also has the advantage of
being a general-purpose solution.

But if I had to choose from among the other solutions, I think I'd
find B the least appealing -- though being one of the people
responsible for maintaining the stylesheets, I guess I need to
admit to a little bias. And based on what I've seen of past
problems with bugs in Xalan, I don't have much confidence in
relying on A happening any time soon.

So, yeah, I think C may best way to go.

By the way, there's another issue with a part of the Apache XML
toolchain -- namely, the XInclude support in Xerces. That support
is buggy (though there is a way to work around it by explicitly
setting xml:base attributes on all your doc instances) and
incomplete (doesn't support XPointers/fragment identifiers).

So an alternative Java-based XInclude processor that worked
correctly and that, ideally, could be used as a drop-in
replacement for the buggy/incomplete Xerces one would be great.

And by "drop-in replacement", I mean one that could enable
single-pass XInclude and XSLT processing, as described in Bob
Stayton's book -

  http://www.sagehill.net/docbookxsl/Xinclude.html#JavaXIncludes

If somebody happened to have, say, an existing standalone XInclude
engine that he might be able to upgrade with some degree of
support for XPointers/fragment identifiers and that could be used
in single-pass processing (call to XInclude resolution gets done
automatically prior to XSLT processing), I would bet he'd get some
enthusiastic support from people in the DocBook community in
testing and debugging it, and some heartfelt gratitude.

  --Mike

smime.p7s