Project

Profile

Help

Bug #4152

closed

Initial template must be public or final: XTDE0040 not reported

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

Status:
Closed
Priority:
Normal
Assignee:
Category:
XSLT 3.0 packages
Sprint/Milestone:
-
Start date:
2019-03-05
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

When an explicit stylesheet package is used, a template intended for use as a named template entry point must be public or final. Saxon does not detect this error. Failure in new XSLT3 test case accept-001a.

Actions #1

Updated by Michael Kay about 5 years ago

  • Category set to XSLT 3.0 packages
  • Status changed from New to Resolved
  • Priority changed from Low to Normal
  • Applies to branch 9.9, trunk added
  • Fix Committed on Branch 9.9, trunk added
Actions #2

Updated by Michael Kay about 5 years ago

Fixed in XsltController.callTemplate()

Actions #3

Updated by Michael Kay about 5 years ago

  • Status changed from Resolved to In Progress

It's more complicated than I thought, because we don't appear to have any logic corresponding to the transformation in the spec section 3.5 that makes modes and templates in an implicit top-level package implicitly public.

Actions #4

Updated by Michael Kay about 5 years ago

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.

Actions #5

Updated by Michael Kay about 5 years ago

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.

Actions #6

Updated by Michael Kay about 5 years ago

  • Status changed from In Progress to Resolved
Actions #7

Updated by Michael Kay about 5 years ago

  • Status changed from Resolved to In Progress

This change creates a problem with exported stylesheets. In effect, a named template with private (or defaulted) visibility can be used as an entry point if it is in an implicit package (rooted at xsl:stylesheet) but not if it is in an explicit package (rooted at xsl:package). The problem is that in a SEF file, we make no distinction between the two cases.

Adding an attribute implicit=true|false to the package element in the SEF.

Also refining the conditions under which we output the "vis" attribute on a component, taking account of whether the attribute was explicit in the original XSLT source.

Actions #8

Updated by Michael Kay about 5 years ago

  • Status changed from In Progress to Resolved
Actions #9

Updated by O'Neil Delpratt about 5 years ago

  • Status changed from Resolved to Closed
  • % Done changed from 0 to 100
  • Fixed in Maintenance Release 9.9.1.2 added

Bug issue fixed in the Saxon 9.9.1.2 maintenance release.

Please register to edit this issue

Also available in: Atom PDF