docbook-apps

I encountered a problem today with the DocBook stylesheet's handling of
recursive XIncludes with the Xerces parser.

DocBook assumes that xml:base attributes are declared relative to one
another. Currently, it combines the path components of all xml:base
attributes recursively until it finds an absolute Uri or reaches the root.

However, at least the Xerces XInclude processor doesn't work like this. The
xml:base attributes are always relative to the starting base directory.

eg. Assuming Book.xml includes Introduction/Part.xml and Part.xml includes
GettingStarted/Chapter.xml the intermediate output after XInclude processing
will look something like this:

<book xml:base="Book.xml">
<part xml:base="Introduction/Part.xml">
<chapter xml:base="Introduction/GettingStarted/Chapter.xml">

</chapter>
</part>
</book>

However, the DocBook v5 "relative-uri" template in "common/common.xsl" will
recursively join the directory components of the path to compute relative
paths for mediaobjects with filerefs. Suppose a fileref of
"images/SomeImage.png" is used inside Chapter.xml, the resulting path
DocBook computes will look like
"Introduction/Introduction/GettingStarted/images/SomeImage.png".

Note the redundant "Introduction" path segment here.

I don't know enough about XInclude to tell whether the behavior of the
Xerces processor is correct or whether DocBook is making an invalid
assumption.

In any case, I disabled the recursive traveral with the following temporary
patch, and now everything is fine:

Index: docbook-xsl-ns/common/common.xsl
===================================================================
--- docbook-xsl-ns/common/common.xsl (revision 1055)
+++ docbook-xsl-ns/common/common.xsl (working copy)
@@ -1722,6 +1722,11 @@


+
<xsl:call-template name="getdir">
<xsl:with-param name="filename" select="$base.elem/@xml:base"/>
</xsl:call-template>

Cheers,
Jeff.

P.S. Nice work on DocBook!

That is a bug in Xerces, see
https://issues.apache.org/jira/browse/XERCESJ-1102

Best Regards,
George
--
George Cristian Bina
<oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger
http://www.oxygenxml.com

Jeff Brown wrote:
> I encountered a problem today with the DocBook stylesheet's handling of
> recursive XIncludes with the Xerces parser.
>
> DocBook assumes that xml:base attributes are declared relative to one
> another. Currently, it combines the path components of all xml:base
> attributes recursively until it finds an absolute Uri or reaches the root.
>
> However, at least the Xerces XInclude processor doesn't work like this. The
> xml:base attributes are always relative to the starting base directory.
>
> eg. Assuming Book.xml includes Introduction/Part.xml and Part.xml includes
> GettingStarted/Chapter.xml the intermediate output after XInclude processing
> will look something like this:
>
> <book xml:base="Book.xml">
> <part xml:base="Introduction/Part.xml">
> <chapter xml:base="Introduction/GettingStarted/Chapter.xml">
>
> </chapter>
> </part>
> </book>
>
> However, the DocBook v5 "relative-uri" template in "common/common.xsl" will
> recursively join the directory components of the path to compute relative
> paths for mediaobjects with filerefs. Suppose a fileref of
> "images/SomeImage.png" is used inside Chapter.xml, the resulting path
> DocBook computes will look like
> "Introduction/Introduction/GettingStarted/images/SomeImage.png".
>
> Note the redundant "Introduction" path segment here.
>
> I don't know enough about XInclude to tell whether the behavior of the
> Xerces processor is correct or whether DocBook is making an invalid
> assumption.
>
> In any case, I disabled the recursive traveral with the following temporary
> patch, and now everything is fine:
>
> Index: docbook-xsl-ns/common/common.xsl
> ===================================================================
> --- docbook-xsl-ns/common/common.xsl (revision 1055)
> +++ docbook-xsl-ns/common/common.xsl (working copy)
> @@ -1722,6 +1722,11 @@
>
>
> +
> <xsl:call-template name="getdir">
> <xsl:with-param name="filename" select="$base.elem/@xml:base"/>
> </xsl:call-template>
>
> Cheers,
> Jeff.
>
> P.S. Nice work on DocBook!
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: docbook-apps-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: docbook-apps-help@lists.oasis-open.org
>

Interesting.
Is it possible to throw in an implementation-specific flag to help users
workaround this particular issue?

Although perhaps with recent activity on the bug we'll actually see a patch
applied sometime soon...

Jeff.


Original Message-----
From: George Cristian Bina [mailto:george@oxygenxml.com]
Sent: Friday, July 18, 2008 5:03 AM
To: Jeff Brown
Cc: docbook-apps@lists.oasis-open.org
Subject: Re: [docbook-apps] Bug: Recursive XInclude incompatibility with
Xerces processor.

That is a bug in Xerces, see
https://issues.apache.org/jira/browse/XERCESJ-1102

Best Regards,
George
--
George Cristian Bina
<oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger
http://www.oxygenxml.com

Jeff Brown wrote:
> I encountered a problem today with the DocBook stylesheet's handling
> of recursive XIncludes with the Xerces parser.
>
> DocBook assumes that xml:base attributes are declared relative to one
> another. Currently, it combines the path components of all xml:base
> attributes recursively until it finds an absolute Uri or reaches the root.
>
> However, at least the Xerces XInclude processor doesn't work like
> this. The xml:base attributes are always relative to the starting base
directory.
>
> eg. Assuming Book.xml includes Introduction/Part.xml and Part.xml
> includes GettingStarted/Chapter.xml the intermediate output after
> XInclude processing will look something like this:
>
> <book xml:base="Book.xml">
> <part xml:base="Introduction/Part.xml">
> <chapter xml:base="Introduction/GettingStarted/Chapter.xml">
>
> </chapter>
> </part>
> </book>
>
> However, the DocBook v5 "relative-uri" template in "common/common.xsl"
> will recursively join the directory components of the path to compute
> relative paths for mediaobjects with filerefs. Suppose a fileref of
> "images/SomeImage.png" is used inside Chapter.xml, the resulting path
> DocBook computes will look like
> "Introduction/Introduction/GettingStarted/images/SomeImage.png".
>
> Note the redundant "Introduction" path segment here.
>
> I don't know enough about XInclude to tell whether the behavior of the
> Xerces processor is correct or whether DocBook is making an invalid
> assumption.
>
> In any case, I disabled the recursive traveral with the following
> temporary patch, and now everything is fine:
>
> Index: docbook-xsl-ns/common/common.xsl
> ===================================================================
> --- docbook-xsl-ns/common/common.xsl (revision 1055)
> +++ docbook-xsl-ns/common/common.xsl (working copy)
> @@ -1722,6 +1722,11 @@
>
>
> +
> <xsl:call-template name="getdir">
> <xsl:with-param name="filename" select="$base.elem/@xml:base"/>
> </xsl:call-template>
>
> Cheers,
> Jeff.
>
> P.S. Nice work on DocBook!
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: docbook-apps-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail:
> docbook-apps-help@lists.oasis-open.org
>

Hi all,

Google and the Adobe PDF specification have let me down; let's see if
anyone here has the answer.

I'd like to be able to insert Acobat "comment" markers into the PDFs
that I generate using the DocbookXSL stylesheets so that reviewers can
simply use the "view next comment" feature in Acrobat rather than
scrolling through long documents looking for visual change markers (we
use DeltaXML to generate and style change markers). I can't find any
information on how to form the markers, etc. Has anyone else ever done
this? Got any ideas?

Thanks,
Jeff.