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
b...@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
titleTest/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
titleArticle 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-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
-
To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
