[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: xml:base and stylesheets
/ "Bob Stayton" <bobs@sagehill.net> was heard to say: | OK, I finally tracked this down. Elliotte's document sets the default | namespace to the DocBook namespace, so that invokes the | mode="stripNS" to strip the namespace from the document so the | stylesheet match patterns can work. In that mode, all nodes are | processed into a temporary tree, which is then converted to a | node-set and processed again with the regular templates. That's why the xml:base attributes have to be added by the stripNS templates. The (stripped) document doesn't have the same base URI as the original, so all relative references are broken. | I found that the template in mode="stripNS" that matches on | imagedata adds an xml:base attribute to the imagedata element in | the temporary node-set if the fileref is a relative path. In retrospect, this was a poor approach to the problem. | But | one bug was that it did not take into account the | $keep.relative.image.uris stylesheet parameter. It should not | add an xml:base if that parameter is one, because it always | computes an absolute xml:base using the Saxon extension. Well, in fact, it always has to make an xml:base available because, for example, the extension that calculates intrinsic graphic sizes for scaling really does need to be able to open the actual image. | Norm, should stripNS even be adding an xml:base attribute at all? | I don't understand why that was part of stripNS. | | In any case, it doesn't seem to be doing it correctly, because it | doesn't take into account any ancestor xml:base values. It just | invokes saxon:systemID() to get a full path, but that is the path | of the main document file, and would not be the path of an image | file in a subdirectory identified by an xml:base on an ancestor | element. Indeed. And now the "right" approach seems both much simpler and much more obviously correct: simply make sure that the root element of the document has an appropriate xml:base attribute. That's where the base needs to be specified, and as you say, the code for dealing with images already knows how to walk up the tree looking for ancestor xml:base attributes. I've made those changes and tested them and indeed they seem to cause the right thing to happen. And they shouldn't interfere with the $keep.relative.image.uris parameter either. Note, however, that there's a different bug in $keep.relative.image.uris. Given: <book xml:base="/share/projects/sourceforge/docbook/testdocs/basetest/"> <bookinfo> <title>Book Title</title> </bookinfo> <chapter xml:base="chaps/chapter1.xml" id="chap"> <title>Chapter title</title> <mediaobject> <imageobject> <imagedata fileref="../images/duck-small.png"/> </imageobject> </mediaobject> </chapter> </book> If $keep.relative.image.uris=1, the output HTML has <img src="../images/duck-small.png"> where it needs <img src="images/duck-small.png"> Fixing this is going to be tricky as it depends on the relationship between the base URI of the original document, the base URI of the element on which @fileref occurs, and the base URI of the *target* HTML file. I haven't tried to fix that, but I checked in my other changes this morning. If no one else has problems, I think we can call this problem (half) solved. Be seeing you, norm -- Norman Walsh <ndw@nwalsh.com> | Everything should be made as http://www.oasis-open.org/docbook/ | simple as possible, but no simpler. Chair, DocBook Technical Committee |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]