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 message is in response to Issue #2 (chameleon modes) in the May 11th working draft. Would they be useful? Emphatically yes. Also, they should work with both <xsl:import> and <xsl:include>, and there should be no restrictions on importing the same module multiple times with different default modes. This would allow you to effectively associate each imported/included template rule with multiple modes, just as you can explicitly do now (along with mode="#current" which would be the effective behavior given the absence of a mode attribute on both xsl:template and xsl:apply-templates). (To avoid function and variable name conflicts, use multiple imports instead of multiple includes; that's no less true today, where a module can be imported multiple times and where this scenario is not treated specially in the language.) Oftentimes, I have a baseline transformation (usually the identity transformation or some modification of it) that I want to re-use. Although I like the idea of setting default-mode="..." on the <xsl:stylesheet> element, it makes much more sense to set it in the importing/including module. The use case, of course, is to re-use and customize an existing read-only code module (perhaps from a library of stylesheets). No one wants to clutter their code with mode="blah" everywhere just in case someone might want to reuse it someday, and default-mode makes that less painful, but it still should be up to the calling stylesheet. If the first user hasn't set default-mode="someArbitraryNameJustInCase" (e.g., because it was implemented in XSLT 2.0), then it still requires the second user to have write access to the imported module (which sucks). This is an opportunity for upgrading XSLT's already powerful modularization mechanisms. Resolving such imports (even multiple imports with different default modes) would be static and mechanical. And I don't see any potential ambiguity problems: #current, #default, and explicitly named (including #unnamed) all are unambiguous. In summary, yes, please do support "chameleon modes," and don't put any arbitrary restrictions on their use (such as only one import mode per module).
Decided we should defer this until we have progressed further with facilities for separate compilation. This may lead to more general mechanisms (a) for the names used in one library package to be non-conflicting with names used in a different package, unless they are part of the interface, and/or (b) aliasing of names imported from a library package so the provider and consumer can use different names for the same thing.
The minutes of the Prague F2F (March 2011) record: We believe our work on packaging satisfies this requirement. (Hint: write a wrapper stylesheet that includes the other; add a mode to the wrapper with a rule that calls apply-templates on the current node, in the default mode; package the result; the default mode is now private to the package.) To expand this, the essence of the requirement is to be able to use multiple modules that were each written to use the unnamed mode and integrate them into a single stylesheet. We can now do this by putting each of the modules in its own package, with a wrapper that does: <xsl:template match="~item()" mode="M"> <xsl:apply-templates/> </xsl:template> and then make "M" a public mode in this package, and the unnamed mode private to the package. I have captured a note on this approach as a note in the spec, which will be expanded, so I am marking the bug fixed. Evan, if you are happy with this outcome, please close the bug. (Alternatively, feel free to wait until you have seen the spec.)