This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This bug was originally reported by mail in the WG, https://lists.w3.org/Archives/Member/w3c-xsl-wg/2014Jul/0055.html (member only). The relevant part of the mail is this: Consider: <xsl:package …> <xsl:use-package _name="package-$debug.xsl" /> <xsl:stylesheet ...> <xsl:param name="debug" select=" 'debug' " /> </xsl:stylesheet> </xsl:package> The problem lies with the scoping of variables. If you specify a parameter inside xsl:stylesheet, the scope (the way I understand it) does not extend beyond the enclosing xsl:stylesheet element (similarly, the param is not available on the xsl:stylesheet element itself). We are allowed to move the xsl:use-package below the xsl:stylesheet element (which solve the tree-traversal order issue of the static param having to appear before its usage). But I don't think this solves the scoping issue. Any idea how to solve this, or am I misinterpreting the scoping rules?
The WG discussed this and considered: 1) allowing static parameters at the xsl:package level 2) allowing required, but without default value params to be scoped at the package declaration level 3) removing the xsl:stylesheet element as a child of xsl:package The WG considered option (1) too restrictive and option (2) undesirable. The conclusion at the F2F of 30 July 2014 was to come up with a proposal for option (3).
We further considered that if we take this direction, there's no longer a strong reason for xsl:package to be a separate element; we could just use xsl:stylesheet/xsl:transform distinguished by a package-name attribute. On the other hand, this potentially creates confusion between xsl:use-package and xsl:import, you lose the clarity that only stylesheets can be imported and only packages can be used. Note that an XSLT 2.0 processor is likely to accept <xsl:stylesheet version="3.0" package-name="xxx"> and run it in forwards-compatibility mode, whereas it is likely to reject <xsl:package version="3.0"> so we would get a compatibility advantage by going this way. This seems to make it easier to convert an existing stylesheet to a package, and have it able to work with both 2.0 and 3.0 processors. Consider our xml-to-json stylesheet, we would just have to add a package name. But then what happens if the package contains an xsl:import and the target of the xsl:import is itself a package (ie. has a package-name)? A 2.0 processor would simply ignore the package name - as well as any @visibility attributes. But a 3.0 processor would reject it, as violating the rule that import fails if the target is a package. We think that's OK. We think this can work and we can see advantages but we're aware it's a radical step and we need time to think about it.
On reflection I think that the proposal in comment #2 is a step too far, if only because of the amount of rework that it causes. But also because I think there is better clarity if the root module of a package is readily distinguished from other modules. So the proposal is as follows: 1. 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 (in any position). 2. xsl:package acquires an id attribute for consistency with stylesheet/transform 3. In 3.6, change the rules for "simplified" packages; in the transformation, replace the body of the template rule by <t:package version="{@version}" 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()"/> </t:package> 4. Remarkably, we do not have any examples of complete packages. Add one! 5. Add an example that illustrates the intended use case for shadow attributes. 6. Generally review the text to make sure we change everything that needs changing; there are no other technical changes, but we need to look for out-of-date examples and notes.
The WG today accepted the proposal in comment #3.
The changes have been applied.