Workaround for xinclude path bug, fixed in xsltproc 1.1.27?

[Warren Young <warren@etr-usa.com>]

Take these three files:

foo.dbx:

    <?xml version="1.0" encoding='UTF-8'?>
    <!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook V4.2//EN"
        "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd";>

    <article>
      <title>Test</title>

      <xi:include href="bar.dbx"
        xmlns:xi="http://www.w3.org/2001/XInclude"/>
    </article>

bar/bar.dbx:

    <?xml version="1.0" encoding='UTF-8'?>
    <!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook V4.2//EN"
        "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd";>

    <sect1>
      <title>Article Section 1</title>

      <para>
        <xi:include href="qux.txt" parse="text"
          xmlns:xi="http://www.w3.org/2001/XInclude"/>
      </para>
    </sect1>

and qux.txt:

    Hi, I am the article's real text.

Now write them to disk, so that foo.dbx and qux.txt are in the current 
working directory, and bar.dbx is in a bar subdirectory.  Then try to 
create an HTML version of the combined document:

    $ xsltproc --xinclude --path .:bar /path/to/html.xsl foo.dbx

You can use any stylesheet you like, it doesn't matter.

If you use xsltproc 1.1.27 or newer, it builds successfully.

Any older version will fail on the second xinclude because it apparently 
binds the "bar" path it determined for the first xinclude to the second 
xinclude call, so it erroneously goes looking for bar/qux.txt instead of 
going back to the --path value and searching all of the directories given.

The problem is, 1.1.27 came out about three years after 1.1.26, so a lot 
of systems will have this problem.  I can't just ask the whole world to 
upgrade to 1.1.27 or newer.

So, does anyone have a workaround for this?

Assume that I cannot know the relative locations of all the files being 
xincluded.  All I get to know is that, at build time, I will learn the 
value for xsltproc's --path value, and that all of the files will be 
somewhere in that set of directories.

Just for completeness, this sort of thing happens when you're using a 
system like the autotools or CMake, which lets you have a build tree 
that is separate from the source tree, and some of your xincluded files 
are generated.  The generated files end up in the build directory, so 
you can end up with xinclude jumps back and forth between the two trees.