RE: [docbook-apps] Bug: Recursive XInclude incompatibility with Xerces processor.

["Jeff Brown" <jeff.brown@gmail.com>]

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">
>       <!-- stuff here, maybe a mediaobject or something -->
>     </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 @@
> 
>    <!-- Recursively resolve xml:base attributes, up to a
>         full path with : in uri -->
> +  <!-- Disabled by Jeff Brown on 7/18/2008 because it turns out that
> +       the Xerces XInclude processor encodes xml:base using the full
> +       path relative to the starting directory rather than using
> +       partial paths relative to the containing element's xml:base
> +       as is assumed by this code.
>    <xsl:if test="$base.elem/ancestor::*[@xml:base != ''] and
>                  not(contains($base.elem/@xml:base, ':'))">
>      <xsl:call-template name="xml.base.dirs"> @@ -1729,6 +1734,7 @@
>                        select="$base.elem/ancestor::*[@xml:base !=
''][1]"/>
>      </xsl:call-template>
>    </xsl:if>
> +  -->
>    <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
>