Re: [docbook-apps] Workaround for xinclude path bug, fixed in xsltproc 1.1.27?

[Bob Stayton <bobs@sagehill.net>]

Hi Warren,
I would be curious to find out the status of the xml:base attributes 
that are inserted by the XML parser when the XIncludes are resolved. The 
XSL stylesheets use those inserted xml:base attributes to adjust 
relative paths for the output files.

If you can run xmllint --xinclude and look in the output for xml:base 
attributes, that might give you a clue.  If the xml:base values are 
wrong, though, I don't know how the XSL templates could know which ones 
are incorrect in order to implement a workaround.

Bob Stayton
Sagehill Enterprises
bobs@sagehill.net

On 9/9/2014 12:26 PM, Warren Young wrote:
> 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.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: docbook-apps-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: docbook-apps-help@lists.oasis-open.org