in html/autoidx.xsl,
<template *name*="reference">
there are two places where "target" is determined as follows:
<xsl:variable name="target" select="key('sections', $zone)[&scope;]"/>
(and the aim of $target is to be passed on to the generation of backlink text with
<xsl:template match="*" mode="index-title-content"> )
If @role and/or @type are set in the <indexentry/> in question, filtering by "[&scope;]" above will have the result, that only those @zone-targets with corresponding @role or @type will be considered for construction of the backlink (and existence @type typically would be against the DTD).
Also suspectible (but admittedly not fully understood) to the same issue:
<xsl:template match="indexterm" *mode*="reference">
...
<xsl:if test="key('endofrange', @id)[&scope;]">
<xsl:apply-templates select="key('endofrange', @id)[&scope;][last()]"
mode="reference">
Logged In: YES
user_id=582041
Originator: NO
Please provide a sample XML document that demonstrates the problem.
small article.xml with two references
Logged In: YES
user_id=57940
Originator: YES
processing the example document with
xsltproc --nonet --stringparam index.on.type 1 /usr/share/docbook-xsl/html/docbook.xsl test.xml
yields:
>>>
...
Index
W
with @zone,
without @zone, ref 1
<<<
'untyped' works fine
xsltproc --nonet --stringparam index.on.type 0 /usr/share/docbook-xsl/html/docbook.xsl test.xml
>>>
...
Index
W
with @zone, ref 1
without @zone, ref 1
<<<
File Added: test.xml
Logged In: YES
user_id=582041
Originator: NO
Someone else should take a look at this bug. I have really tried to understand what's going on, but I'm stumped.
Logged In: YES
user_id=57940
Originator: YES
changing
<xsl:variable name="target" select="key('sections', $zone)[&scope;]"/>
to
<xsl:variable name="target" select="key('sections', $zone)"/>
does solve the problem for me, but I did not test everything thouroughly, hoping for someone to understand what is going on there.
My understanding is that filtering by [&scope;] is applied every time when an index entry has to be created (maybe the target is out of scope) to check wether role and or type match.
But here this is already verified and the template in question simply tries to determine the caption for the index entry. There is only one candiate (the enclosing section) but you typically cannot expect this to have @role or @type attributes on itself.
As for the second template: usage of [&scope;] there also somehow seemed atypical to me, but I did not investigate as far as to even know what the template is about :-(
Logged In: YES
user_id=582041
Originator: NO
A fix for this issue has been added to the current codebase.
Please test the fix with the latest snapshot from:
http://docbook.sourceforge.net/snapshots/
Logged In: YES
user_id=582041
Originator: NO
I took another look at this, and the suggestion to remove [&scope;] from the target variable in the template with name="reference" makes sense (and it works!). When the index reference (backlink) is about to be output, it has already been established that the indexterm is "within scope". The scope filter should not be applied to the target of the link.
Logged In: YES
user_id=1312539
Originator: NO
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).