Project

Profile

Help

Bug #4155

closed

<xsl:expose component="mode"> has no effect on implicitly-declared modes

Added by Michael Kay about 3 years ago. Updated about 3 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
XSLT 3.0 packages
Sprint/Milestone:
-
Start date:
2019-03-06
Due date:
% Done:

100%

Estimated time:
Legacy ID:
Applies to branch:
9.9, trunk
Fix Committed on Branch:
9.9, trunk
Fixed in Maintenance Release:
Platforms:

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.

Actions #1

Updated by Michael Kay about 3 years ago

  • 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.

Actions #2

Updated by Michael Kay about 3 years ago

These changes are causing some regression:

accept : 9 expose : 5 override : 3

Actions #3

Updated by Michael Kay about 3 years ago

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.

Actions #4

Updated by Michael Kay about 3 years ago

  • 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).

Actions #5

Updated by O'Neil Delpratt about 3 years ago

  • 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