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.netOn 9/9/2014 12:26 PM, Warren Young wrote:
> Take these three files:
>
> foo.dbx:
>
>
> > "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
>
>
>
>
> <xi:include href="bar.dbx"
> xmlns:xi="http://www.w3.org/2001/XInclude"/>
> >
> bar/bar.dbx:
>
>
> > "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
>
> <sect1>
>
>
> <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>
>
>