OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

docbook-apps message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Workaround for xinclude path bug, fixed in xsltproc 1.1.27?

Take these three files:


    <?xml version="1.0" encoding='UTF-8'?>
    <!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook V4.2//EN"


      <xi:include href="bar.dbx"


    <?xml version="1.0" encoding='UTF-8'?>
    <!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook V4.2//EN"

      <title>Article Section 1</title>

        <xi:include href="qux.txt" parse="text"

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.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]