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: Re: [docbook-apps] Workaround for xinclude path bug, fixed in xsltproc 1.1.27?

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

On 9/9/2014 12:26 PM, Warren Young wrote:
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.

To unsubscribe, e-mail: docbook-apps-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-help@lists.oasis-open.org

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