This was a bug in the xml.base.dirs template in common/common.xsl that I
fixed and checked in.
This was interesting because the bug was exhibited when processing with
Saxon, but not with xsltproc. The problem occured when more than one
element in an image's ancestry had an absolute URI. The recursion process
that resolves nested xml:base attributes should have stopped when it hit an
absolute URI (one with a ":" in it). It didn't, so it munged them
together. Now it works properly (in the next snapshot).
You're wondering where the second absolute URI came from, since your file
had only one. Therein lies a story.
The DocBook XSL stylesheets were written to handle a DocBook 4 document,
which is not in a namespace. DocBook 5 documents are in a namespace. But
those docbook elements in a namespace are not matched by the existing
templates, so the stylesheet first strips the namespace. To do that in one
pass, Norm wrote the template that processes the document in stripNS mode
to remove the namespace, saves the result into a variable, converts the
variable into a nodeset using exslt, and then processes the nodeset with
the regular stylesheet templates.
In addition to stripping the namespace, this process also adds an xml:base
attribute to the root element. As Norm explained, this is necessary because
a nodeset doesn't have an xml:base since it was created in memory. Some
processing steps may need an xml:base on the root element to work properly.
In 1.70.1, Norm added a template named 'add-xml-base' to to
common/stripns.xsl do that. That template is called only when processing a
DocBook 5 document because it gets put into a nodeset before applying the
regular templates. But there is no standard function in XSLT 1.0 for
identifying the xml:base of the current document. However, there is a Saxon
extension function saxon:systemId that can do that. So add-xml-base checks
to see if that function exists, and if it does, it computes the xml:base of
the document and adds that attribute to the root element in the internal
nodeset. It computes an absolute URI, so that's where the second nested
absolute URI came from. And that's why the problem is not exhibited in
xsltproc, because it does not have an extension function to add an xml:base
to the root element in the internal nodeset.
Because that extra xml:base on the root element in the internal nodeset is
not visible, it took a run through the Oxygen debugger to see where it was
coming from.
Bob Stayton
Sagehill Enterprises
DocBook Consulting
bobs@sagehill.net----- Original Message -----
From: "Elliotte Harold" <
elharo@metalab.unc.edu>
To: "Bob Stayton" <
bobs@sagehill.net>
Cc: <
docbook-apps@lists.oasis-open.org>
Sent: Friday, August 11, 2006 4:19 PM
Subject: Re: [docbook-apps] xml:base and DocBook stylesheets
> Bob Stayton wrote:
>> Hi Elliotte,
>> Some xml:base problems may be due to the stylesheets, and some may be
>> due to bugs in the way the XInclude parser adds xml:base attributes
>> (I've reported several over the last couple of years on libxml2). I
>> could track this down if you submit a bug report on sourceforge with a
>> compact set of files that demonstrate the problem, and let me know how
>> you are processing the files.
>>
>
> I've now submitted the requested bug and test case:
>
>
http://sourceforge.net/tracker/index.php?func=detail&aid=1539010&group_id=21935&atid=373747>
> Holler if you need any more details.
>
>
> --
> ?Elliotte Rusty Harold
elharo@metalab.unc.edu> Java I/O 2nd Edition Just Published!
>
http://www.cafeaulait.org/books/javaio2/>
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/>
>