Thanks for the explanation on this Mike.
The additional twist I've found to this is that even with the patch, the
footnote numbers are not output. I believe this is do to the following
section of the ulink.footnote.number template in fo/xref.xsl:
<xsl:number level="any"
from="d:chapter|d:appendix|d:preface|d:article|d:refentry|d:bibliography[not(parent::d:article)]"
count="d:footnote[not(@label)][not(ancestor::d:tgroup)]|d:ulink[node()][@url
!= .][not(ancestor::d:footnote)]"
format="1"/>
We can replace the ulink with link for the XSL-NS stylesheets but that
raises a couple of questions:
1. How can we change the footnote number so that links to external
sites are counted, but internal links are not? (I'm not familiar enough with
XPATH expressions and predicates to do this properly).
2. If we do change the non-namespaced XSL stylesheets source as you
suggest, then the footnote count would need to handle both ulink (as it does
now) as well as handling the link changes. Can we do this with a single
<xsl:number.../> or would we have to split things up?
Ken
On 9/6/07, Michael(tm) Smith <
smith@sideshowbarker.net> wrote:
>
> Ken Morse <
kenneth.morse@gmail.com>, 2007-09-05 15:25 -0400:
>
> > I figured out what was happening and attached a patch to the issue in
> the
> > bugtracker. When the XSL stylesheets detect a 5.0 document (using
> > namespace), the stripns.xsl stylesheet converts a link to a ulink if the
> > link points to an external reference. The XSL-NS stylesheets have no
> such
> > conversion so link (in fo/xref.xsl) has been patched to call the ulink
> > template if the link points to an external reference.
>
> I see -- so more specifically, it looks like your patch causes the
> template for the DocBook-namespaced link element to checks and see
> if any link has an xlink:href or href attribute; if it finds one
> that does, and the href value is non-empty and doesn't start with
> a hash sign, then it calls the ulink template and passes the href
> value as the value of the url parameter for that template.
>
> And if it doesn't find an xlink:href or href attribute at all, the
> link template just does the same thing it's already doing now.
>
> So that all looks correct to me.
>
> > Although I built a patch for the xref.xsl file, I'm not sure this is
> helpful
> > since I don't know how the XSL-NS Stylesheets are currently built. If
> they
> > are still built by transforming the XSL stylesheets
>
> They are still build for the non-namespaced XSL stylesheets and
> are likely to continue to be built that way for as long as they
> continue to be maintained and available (which is probably means
> until we moved over completely to a set of natively
> namespace-aware XSLT 2.0 stylesheets).
>
> > then a special transformation for link in fo/xref.xsl would need
> > to be added.
>
> Actually, I think we can probably just add your patch (or
> something the achieves the same effect) to the non-namespaced
> XSL stylesheets source. Though it's true that in DocBook 4 and
> before, xlink:href and href are not valid attributes on link, the
> XSL stylesheets don't need to be limited to processing only what's
> valid in DocBook 4. If we add the check for href to the XSL
> stylesheet source, I think it may just get copied over unchanged
> to the corresponding template in the generated XSL-NS stylesheets
> -- and that check for href will be harmless as far as processing
> instances of DocBook 4 and before, because the code will just
> never get exercised (always evaluate to false) when processing
> valid instances DocBook 4 and before.
>
> But I'll need to try adding it and then running the XSL-NS build
> to see if that's actually the case or not. If it's not, then I
> think Bob (who's the one that created the XSL-NS build) will need
> to take a look at it and figure what needs to be done.
>
> --Mike
>
>