[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [docbook-apps] Bug: Recursive XInclude incompatibility with Xerces processor.
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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]