OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

docbook-apps message

[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 |

PGP signature



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]