On 17.01.2023 at 23:43, Karl O. Pinc wrote:
> It's good you asked. After poking about the XSLT 1.0 spec to refresh
> my memory I abandoned the "mode" approach entirely. The real "right
> way" is to use the import mechanism.
It actually is not.
After quite some time trying to figure out why things don't work as
intended, I ended up reading the XSLT 1.0 spec.
As the name already suggests, <xsl:apply-imports> is closely related to
<xsl:apply-templates> with the difference that it *applies* a *template
rule* from an imported style sheet instead of applying a template rule
from the current style sheet
(https://www.w3.org/TR/1999/REC-xslt-19991116#apply-imports). What it
does not do is *calling* a *named template*
(https://www.w3.org/TR/1999/REC-xslt-19991116#named-templates).
What this basically means is that in XSLT 1.0 you can use
<xsl:apply-imports> to override template rules (<xsl:template
match="this-pattern-inside-match-makes-it-a-template-rule">) but you
cannot use it to override named templates (<xsl:template
name="this-id-inside-name-makes-it-a-named-template">). If you want to
override named templates you basically have to duplicate and change them.
While there are mechanisms to call overriden named templates in XSLT 3,
this is out of scope here, since we're bound to XSLT 1.0
As a consequence, there was little I could change in the initial patch
to avoid the code duplication and all attempts to do so, ultimately led
to even longer and more complex code without really reducing the amount
of duplication.
The <xsl:apply-imports> approach actually does work in the varlistentry
case, although this doesn't really change a lot regarding the length of
the patch (it's a bit nicer though since in this case it really avoids
duplication). I've also taken the advice to terminate the build and
print the xpath if a required id is missing.
The attached patch is my best-effort approach to implement discoverable
links.
Best regards,
Brar