This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 27300 - [XSLT30] Simplified package visibility of components, esp. xsl:function
Summary: [XSLT30] Simplified package visibility of components, esp. xsl:function
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 3.0 (show other bugs)
Version: Last Call drafts
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
Depends on:
Reported: 2014-11-11 11:18 UTC by Abel Braaksma
Modified: 2015-10-29 09:50 UTC (History)
1 user (show)

See Also:


Description Abel Braaksma 2014-11-11 11:18:36 UTC
This was initially brought to attention by Dimitre Novatchev (see

The transformation for simplified packages does not include xsl:function and so does not make its implicit visibility public, even though it is a callable component:

 <xsl:transform version="3.0" 
    <xsl:namespace-alias stylesheet-prefix="t" result-prefix="xsl"/>
    <xsl:template match="xsl:stylesheet|xsl:transform">
      <t:package declared-modes="no">
        <xsl:copy-of select="@*"/>
        <t:expose component="mode" names="*" visibility="public"/>
        <t:expose component="template" names="*" visibility="public"/>
        <xsl:copy-of select="node()"/>

Other components not included are xsl:accumulator and xsl:variable. Even if their intentional implicit visibility is private, perhaps it still makes sense to make that explicit in the transformation, if anything, then just to forgo the perceived ambiguity mentioned in Dimitre's mail.
Comment 1 Michael Kay 2014-11-21 10:14:25 UTC
Reviewed by the WG on 2014-11-20.

The reason that we make named templates and modes public, but not other components, is for backwards compatibility. The purpose of "simplified packages" is to allow an XSLT 2.0 stylesheet to be used unchanged as a package. To allow the XSLT 2.0 styles of invocation using a named initial mode or a named initial template, the modes and templates must be public. XSLT 2.0 does not allow invocation using (for example) named functions) so we treat the functions as private.

We should perhaps emphasize that when the simplified syntax is used, you are restricted to a single-package application. The implicit package cannot use any other packages because use-package cannot appear as a child of xsl:stylesheet, and it cannot be used by any other package because it has no package name.

We are not proposing to make any technical change in response to this comment, though we will look at whether is scope for clearer explanations.
Comment 2 Abel Braaksma 2014-12-01 13:28:29 UTC
> and it cannot be used by any other package because it has no package name.

Sorry, but this seems not true, at least not in the current Draft. After the change to make xsl:stylesheet/transform a synonym for an (implicit) xsl:package, we allowed xsl:use-package as a child of xsl:stylesheet (I think, but recollection can be wrong).

This is reflected in the current draft:



  name = uri
  package-version? = string >
  <!-- Content: (xsl:accept | xsl:override)* -->

Permitted parent elements:


Under xsl:stylesheet/transform we say:
* <!-- Content: (declarations) -->

and, remarkably, or deliberately (?), xsl:use-package is not marked as a declaration per se.

However, I also see in the XSLT 3.0 public LCWD:
- Bug 24438: Drop support for xsl:use-package as a child of xsl:stylesheet.

And, bug 26468 seems to reflect that xsl:use-package is not allowed, quote: "xsl:package has the same content model as xsl:stylesheet/transform, with the addition that it allows xsl:expose and xsl:use-package elements to appear as children"

Tentative conclusion: the "permitted parent elements" is incorrect, as text and other bug reports, and comment#1 above indicate otherwise.

In addition, we say:
[Definition: The content of the xsl:package element is referred to as the package manifest].

Should we somehow make explicit, through a NOTE or otherwise, that an *implicit* package is not considered a package manifest by that definition?
Comment 3 Michael Kay 2014-12-12 17:32:41 UTC
As regards the original bug and resolution, I think they stand: in an implicit package, only templates and modes are made public, and the reason for this is because in XSLT 2.0, these are the only components that need to be referenced externally from an API.

Abel is right to correct me that xsl:use-package is now allowed as a child of xsl:stylesheet.

In addition, given the definitions:

[Definition: An element occurring as a child of an xsl:stylesheet, xsl:transform, or xsl:override element is called a top-level element.]

[Definition: Top-level elements fall into two categories: declarations, and user-defined data elements. Top-level elements whose names are in the XSLT namespace are declarations. 

xsl:use-package should clearly be classified as a declaration. I have fixed this in the element syntax catalog.