[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [docbook-apps] xml:base and DocBook stylesheets
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/ > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]