Saxon

Fixed in XsltController.callTemplate()

Looking into the logic here is revealing quite a few little issues.

Firstly, the problem applies to modes as well as to named templates; this requires enhancement to the logic for XsltController.applyTemplates() as well as callTemplate().

We need to consider two cases: (a) where the mode/template has an explicit declared visibility of private, and (b) where it is implicitly private because it is in an explicit package (rooted at xsl:package rather than xsl:stylesheet) and has no visibility attribute. We also need to consider the effect of xsl:expose.

The rules for the top-level (root) package of a stylesheet are different, in that modes/template are implicitly public if this package is "implicit" (that is, rooted at xsl:stylesheet or xsl:transform). But a compiled package can be a top-level package in one stylesheet, and a library package in another. So rather than modifying the visibility property of the component for this case, I'm detecting it in the logic for validating the initial template/mode in XsltController.

It seems that when visibility="private" appears on a mode, mode.getDeclaredVisibility() returns null, which is surely wrong.

There's a spec bug here: see https://www.w3.org/Bugs/Public/show_bug.cgi?id=30405

There are a lot of tests that do something like

<xsl:mode name="m" streamable="yes"/>

and then use "m" as the initial mode.

According to §6.6.1 in the spec, the default for xsl:mode/@visibility is "private", and a private mode cannot be used as the initial mode. However, the rules in §2.3.3 appear to differ: provided that declared-modes="no", it's enough to have a template rule in a particular mode to make that mode eligible as an initial mode.

We're going to get compatibility problems if we make such modes ineligible, but I'm inclined to make the change and be damned. Fewer users will be affected if we change it now than if we make the change in a year's time.