[Bug 9721] New: [XSLT 2.1] Support for chameleon modes


           Summary: [XSLT 2.1] Support for chameleon modes
           Product: XPath / XQuery / XSLT
           Version: Working drafts
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XSLT 2.1
        AssignedTo: mike@saxonica.com
        ReportedBy: evan@evanlenz.net
         QAContact: public-qt-comments@w3.org

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

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

Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Wednesday, 12 May 2010 19:43:21 UTC