Bug #4155
closed
<xsl:expose component="mode"> has no effect on implicitly-declared modes
Category:
XSLT 3.0 packages
Applies to branch:
9.9, trunk
Fix Committed on Branch:
9.9, trunk
Fixed in Maintenance Release:
Description
Although it's not 100% clear in the spec, on balance I think xsl:expose should be capable of setting the visibility of a mode that is defined "by reference" rather than through an explicit xsl:mode declaration.
It's actually having no effect, because PrincipalStylesheetModule.adjustExposedVisibility iterates over "topLevel", which only reaches explicitly-declared components.
Test case package-001j applies.
- Status changed from New to In Progress
I've started by moving the call on PSM.adjustExposedVisibility(), Instead of Compilation.compilePackage() calling this before it calls PSM.compile(), it is now called from within PSM.compile(), after implicit modes have been registered. This change appears to cause no regression.
This means that at the time we call adjustExposedVisibility(), the implicit modes are now present in the RuleManager.
Next, I have changed PSM.adjustExposedVisibility() to iterate over the components in the component index, rather than the top-level declarations in the source stylesheet. This means we pick up the implicit modes.
However, test package-001j is still failing. Saxon treats the mode as being eligible as an initial mode, because it satisfies rule 5 of the eligibility criteria, despite being exposed as private. This is a spec issue: see spec bug 30405.
These changes are causing some regression:
accept : 9
expose : 5
override : 3
Made further changes: instead of simply recording whether the visibility of a component is explicit or implicit, we now capture the provenance of the visibility property as one of implicit, declared, exposed, accepted, derived. This is needed because of the subtleties of the rules for which templates and modes can be used as initial template / initial mode.
Still seeing some regressions, in test sets package and override.
- Status changed from In Progress to Resolved
- Applies to branch 9.9, trunk added
- Fix Committed on Branch 9.9, trunk added
Fixed on 9.9 and trunk. The changes were surprisingly extensive, as they involved keeping more detailed information on a component about how its visibility was computed (new class VisibilityProvenance).
- Status changed from Resolved to Closed
- % Done changed from 0 to 100
- Fixed in Maintenance Release 9.9.1.3 added
Bug fix applied to the Saxon 9.9.1.3 maintenance release
Please register to edit this issue
Also available in: Atom
PDF
.